Do not duplicate JSpecify annotations when several annotations map to one

[timtebeek]

• Fixes JSpecifyBestPractices add @Nullable annotionen to params twice #1199

When an element carries two nullability annotations that both migrate to the same JSpecify annotation, each ChangeType step rewrites its own annotation and the element ends up annotated twice:

import javax.annotation.CheckForNull;
import javax.annotation.Nullable;

class Foo {
    public void bar(@Nullable @org.jetbrains.annotations.Nullable String baz) {
    }
}

migrated to @Nullable @Nullable String baz (fully qualified on the second one whenever the simple name could not be shortened, matching the output in the issue).

This adds a RemoveDuplicateAnnotations recipe that drops annotations repeated on the same element -- leading annotations on classes, methods and variables, annotations attached to modifiers, and type-use annotations on array types, nested types and type arguments -- keeping the first occurrence. It is run at the end of each MigrateFrom* recipe, so it also covers duplicates that only appear once two different MigrateFrom* recipes have both run.

Only annotations that are semantically equal to an earlier one are removed, so distinct annotations such as @Nullable @NonNull are left alone.

[timtebeek]

Moved the recipe out to rewrite-static-analysis: openrewrite/rewrite-static-analysis#1000. It is not JSpecify-specific — any many-to-one ChangeType mapping can leave an element annotated twice — so it now sits next to RemoveDuplicateConditions, with an optional annotationType defaulting to any annotation and a guard so @Repeatable annotations are never deduplicated.

Marked as draft: this PR is now just the six jspecify.yml references plus the end-to-end test, so it stays red until #1000 merges and a snapshot is published. Verified locally against a publishToMavenLocal build of #1000.