Lazily restore serialized S7 classes

[hadley]

Stacked on #743. Review only the changes relative to issue-742-shared-class-reference.

This replaces the environment-backed class reference from #743 with a per-object external pointer. Its live address is the S7 class object. R serialization clears that address, allowing package classes to be restored without serializing their definitions.

For package classes, the serialized tag contains the package/name identity. On first class access after restoration, S7 resolves the current namespace binding, updates the object dispatch vector, validates that object once, and caches the resolved class. Each object has its own pointer, so every restored object is validated independently. If validation fails, the pointer is cleared so a later access retries rather than caching an invalid restoration.

Classes with package = NULL cannot be looked up after restoration. Their class definition is therefore retained in one shared environment in the pointer protected field and serialized with their instances. R deduplicates that environment when multiple instances are serialized together. This removes the weak-reference/session-registry machinery from the original prototype and supports restoration in a fresh R session.

Benchmarks against #743 (construction timings average two paired runs):

case	#743	this PR	change
construct depth 1	27.6 µs	28.1 µs	+2.0%
construct depth 5	138.1 µs	141.9 µs	+2.8%
construct depth 10	286.2 µs	298.9 µs	+4.4%
construct width 50	406.6 µs	422.3 µs	+3.8%
marginal memory per instance	168 B	288 B	+120 B
serialized package depth-1 object	62,389 B	280 B	-99.6%
serialized package depth-10 object	155,513 B	462 B	-99.7%
serialized 100 package depth-10 objects	180,667 B	39,674 B	-78.0%
serialized 100 local depth-10 objects	166,593 B	180,011 B	+8.1%

Validation:

• devtools::test(): 1,298 passed
• devtools::check(): 0 errors; existing test dependency warning and existing/environmental notes only
• air format .
• git diff --check

[t-kalinowski]

I don't think we anticipate users creating many class definitions, but it's worth noting that R_ReleaseObject is quite expensive, and if we ever need to we could do something much more efficient here using a protected link list.