jextract/jni: Overhaul generic specialization to prevent cache contamination

[sidepelican]

Motivation

This PR refactors the generic specialization logic to address a cache contamination issue in JNISwift2JavaGenerator.

The results of translatedDecl(for:) are not constant; they change based on the internal state (Context), such as currentJavaIdentifiers.
If translatedDecl(for:) is called after the context has changed, it may return incorrect results.

While this hasn't been a major issue so far because ImportedFunc is typically used within a single context, the problem surfaced during my attempt to support label overloading in JNI. In that case, the same ImportedFunc is reused across multiple specialized contexts, making the cache contamination problematic.

Solution

Ideally, the correct approach would be to clear the cache whenever the context changes.
However, with the current implementation, I think it difficult to accurately track these context changes.
I am not confident that I can correctly identify and cover all states that are implicitly relied upon.

Instead, I have decided to change the implementation strategy for specialization.
I will stop reusing the same ImportedFunc and instead have each specialized class maintain its own dedicated ImportedFunc instance.
By doing this, we can reduce many of the branches currently used for specialization within JNISwift2JavaGenerator.

[ktoso]

I like killing off the varsity and getters there; overall nice cleanup, thanks