[JExtract] Consider optional control over enum copying

While implementing enums for JNI, we had to decide whether enum values should be copied on the Swift side or Java side. This had implications for whether we were able to use record or not to represent enum cases. We decided to eagerly copy the associated values from Java to Swift, instead of having a pointer to Swift. The latter approach would be more expensive for multiple accceses to the same field (as that would mean more JNI calls), but the former is more expensive for a single access (due to JNI reflection).

We could introduce options to customize this behaviour if the users wanted to have lazy copying for example (so just a pointer to Swift memory). It could be an annotation on the type.

Benchmarks

Here are some benchmarks we ran to compare Java vs Swift copying

Accessing two associated fields (no caching).

Benchmark                 Mode  Cnt     Score    Error  Units
EnumBenchmark.java_copy   avgt   30  1317,810 ± 16,443  ns/op
EnumBenchmark.swift_copy  avgt   30   326,424 ±  7,123  ns/op

Accessing two associated fields (cache JNI IDs in java_copy).

Benchmark                 Mode  Cnt    Score    Error  Units
EnumBenchmark.java_copy   avgt   30  505,537 ± 10,408  ns/op
EnumBenchmark.swift_copy  avgt   30  319,474 ±  5,692  ns/op

Accessing a single associated field (cache JNI IDs in java_copy).

Benchmark                 Mode  Cnt    Score    Error  Units
EnumBenchmark.java_copy   avgt   30  513,441 ±  8,825  ns/op
EnumBenchmark.swift_copy  avgt   30  437,693 ± 15,914  ns/op

Begin with JExtract's enum generation path and the JNI enum implementation described in the issue. Read EnumBenchmark.java and compare the existing eager-copy behavior with the proposed configurable behavior. Done requires a settled option or annotation design and benchmarks or tests showing both modes.