recompile downstream when Java annotation changes

[SethTisue]

fixes #630

[SethTisue]

Jason thinks the approach sounds good and notes,

Looks like Java annotations all have the same parent interface:

The direct superinterface type of an annotation interface is always
java.lang.annotation.Annotation (§9.1.3).

So we don't need to do any sort of transitive invalidation

[SethTisue]

My initial implementation temporarily, kludgily overloaded the hasMacro flag to mean "has macro declaration or annotation definition", just as a quick way to get the tests passing.

The theme for today was to figure out what to do instead. I initially assumed that I would need to add an hasAnnotation flag to AnalyzedClass, alongside the existing hasMacro flag, and that would mean changing both the contraband and the protobuf.

But after discussion with @dwijnand and @retronym, we decided that would be overkill. We suspect that the hasMacro flag exists because the invalidation situation with macros is more complex: there is the definition and the separate implementation, and when the implementation changes we need to treat that (unlike the body of an ordinary method changing) as an API change.

But here the situation is simpler, so they suggested we could just have detectAPIChanges in IncrementalCommon directly check the parents to see if java.lang.annotation.Annotation is present.

And that approach seems to be working out.

[SethTisue]

I think this is ready to go, but there's a customer that might like to test it before merge.

[SethTisue]

@dwijnand I've review-requested you, but also, do you think there's anyone else who should or might like to take a look?

[SethTisue]

(rebased, without any changes)

[eed3si9n]

I am gonna merge this so it'll be part of 1.7.0.

[SethTisue]

regression report at sbt/sbt#6969 — I'll work on a fix pronto