JNI: fix existential result boxing in Swift 6 language mode

[Om-singhaI]

When a JNI function returns any P or some P, the thunk boxes the result with this:

#if hasFeature(ImplicitOpenExistentials)
let resultBoxed$: (Int64, Int64) = {
  let value = resultExistential$
  let pointer = UnsafeMutablePointer<type(of: value)>.allocate(capacity: 1)
  ...

type(of: value) is a value, not a type, so it can't be a generic argument. Swift 5 mode never takes that branch, and the JNI sample app is the only package in CI that extracts any P or some P returns (ReturnProtocol.swift and others). It builds with .swiftLanguageMode(.v5), so CI doesn't compile it. In Swift 6 mode, or with the ImplicitOpenExistentials upcoming feature on, the generated file fails to build:

error: '>' is not a postfix unary operator
error: generic parameter 'Pointee' could not be inferred

This is the Swift 6 failure I mentioned at the end of #925, and one of the cases behind #472.

The resultBox$<T> helper now sits above the #if, and the feature branch calls it directly. With implicit opening that call opens the existential, so T is the concrete type, the same as _openExistential gives in Swift 5. The existential property setter already does it this way. Swift 5 mode compiles the same code as before.

I added returnsExistentialProtocol_boxing_swift to JNIProtocolTests. It fails without the source change, and JNIProtocolTests and JNIAsyncTests pass with it.

I also typechecked the generated thunks with swiftc (Swift 6.4) for the JNI sample's ReturnProtocol.swift, plus a computed property and a class method returning any P. On main they fail with the errors above in Swift 6 mode and with -enable-upcoming-feature ImplicitOpenExistentials. With this change they are clean in both of those and in Swift 5 mode. A small runtime check confirmed that in Swift 6 the helper gets the concrete type, not any P.

[ktoso]

Can you please add a runtime test exercising this path so we're confident it functions
Runtime tests are located inside the samples basically writing the s swift and Java sides as if you were to use this normally

[Om-singhaI]

I turned on the ImplicitOpenExistentials upcoming feature for MySwiftLibrary in the JNI sample, so ReturnProtocolTest and the other protocol tests now run the hasFeature(ImplicitOpenExistentials) code at runtime. I also added a GreeterFactory class with tests for a method and a computed property returning any Greeter and a method returning some Greeter, and they check that the returned value keeps its concrete Swift type. With the generator change reverted, the sample fails to build with the two errors from the description. One tradeoff is that the sample no longer runs the _openExistential path, so if you would rather keep both covered I can move the new code into a separate target.