[graalvmbot]

Move MethodRef, MethodPointer, and MethodOffset into guest staging while keeping their ResolvedJavaMethod targets in the builder. Creation and target lookup go through MethodRefSupport; default selection and flag validation remain in the guest classes.

Switching builder access to JavaConstant / GuestAccess is intentionally left for a follow-up.

Explicit ObjectCopier handling

SVMImageLayerSnapshotUtil registers a dedicated builtin for method references. Default field-based copying would bypass the factories and cannot restore the target association once the method is no longer stored in the reference itself.

The builtin explicitly encodes the target through the existing analysis/hosted method codecs and preserves the pointer/offset kind and permitsRewriteToPLT. Decoding reconstructs references through MethodRefSupport, registering them in the current build. This manual handling, including the hosted-to-analysis decoding policy, deserves particular attention.

Method association: open design question

MethodRefSupport currently owns a build-scoped EconomicMap<MethodRef, ResolvedJavaMethod>. It uses identity comparison with system identity hashing, since word objects cannot generally use normal equals() / hashCode(). Registration and lookup are synchronized, and the exact supplied method object is retained, including its analysis/hosted representation and variant. The registry is recreated for each build/layer rather than persisted.

Is this build-scoped object-identity mapping the right association to keep, or should it be represented differently for the JavaConstant-based follow-up? The mapping strategy is an open point for review, not a settled long-term design.

Reviewer Notes

Please review commit by commit: the preparatory changes, relocation, and mechanical import updates are kept separate.