Walk JavaType refs embedded in annotation element values

[knutwannheden]

What's changed?

JavaTypeVisitor.visitAnnotation only visited annotation.getType(), leaving the refs inside element values untouched: the element meta-variable and SingleElementValue.referenceValue / ArrayElementValue.referenceValues. Any downstream visitor that relies on the full-graph walk (dedup, type remappers, serializers, …) sees non-canonical instances inside annotation values while the rest of the type graph is consistent.

Adds visitAnnotationElementValue, which visits the element meta-variable and the reference-value branch, and reconstructs the ElementValue only when a returned instance changed identity. UnsafeJavaTypeVisitor inherits the new behaviour through the default visitAnnotation.

Constant values are deliberately not visited: SingleElementValue.from / ArrayElementValue.from route any JavaType-valued argument into the reference branch, so constants only ever hold primitives, strings, and enums in parser-produced LSTs.

What's your motivation?

Downstream at Moderne, a recipe run against a large multi-module LST failed deserializing a method's annotations — the meta.bin type table referenced an index past its own end. Root cause was our JavaTypeDeduplicationVisitor inheriting this visit gap: annotation-value refs stayed as pre-canonical instances while the rest of the type graph was deduped, so the writer's identity-keyed map treated them as fresh types after the offset table had already been sized.

Fixing only in our downstream visitor leaves the gap in every other JavaTypeVisitor subclass, which is why this PR is here.

Anything in particular you'd like reviewers to focus on?

• Whether the "no constants" decision matches your understanding of the from(...) factories.
• The ArrayElementValue reference-values loop returns the same array when every visited element is identity-equal, and only clones when at least one changed.