Fix Int? argument issues on 32-bit environments

[sidepelican]

This PR fixes issues related to Int? arguments on 32-bit architectures.
The generated code contained numerous errors. (The failing CI run: https://github.com/swiftlang/swift-java/actions/runs/23786261629/job/69318324924 )

Background

During my investigation, I realized that the dynamic nature of Int.JNIType was significantly complicating the logic.
I have already submitted a PR to address this: swiftlang/swift-java-jni-core#16

In this PR, I have removed the various implementation pieces that were previously used to manually wrap Int into Int64.
With the unified JNIType, these are no longer necessary, and removing them resolves the original problem.

Verification

I have verified that the generated code compiles correctly for 32-bit by running the following command in SwiftJavaExtractJNISampleApp:

./gradlew assemble -PswiftSdk=armv7-unknown-linux-android28

While the compilation is successful, I do not have a 32-bit Android runtime environment, so I haven't been able to verify the actual execution results.

[sidepelican]

Sorry, I forgot to point this out; This PR requires swiftlang/swift-java-jni-core#16 to be merged first.

[ktoso]

I see... let's get some Android folks to chime in here, @madsodgaard has an interest in keeping those 32bit runtimes happy.

[marcprux]

If I'm reading this right, I do think it introduces peril for 32-bit platforms like armv7 on Android and other embedded devices.

In swiftlang/swift-java-jni-core#16 (comment) I suggest simply dropping Int conformance to JavaValue, since I don't think there is really any right way to do it for all platforms.

[ktoso]

Not supporting Int at all is not an option.

There's tons of Swift libs out there using Int and I don't want to be in the business of making idiomatic nice Swift libs have to start writing Int64 just "because swift-java can't handle it". Idiomatic swift libs must import properly, and especially with most systems being 64bit I don't think this is worth making life hard for everyone.

If I'm reading this right, I do think it introduces peril for 32-bit platforms like armv7 on Android and other embedded devices.

I'm not sure how to be honest, can you think of something? We're widening and swift jextract actually checks for overflows; manual users of jni-core may need to do the same, but I don't see it breaking anything 🤔