Previously, optimized_symbol_parsing would enable a fast path for
symbols but it never actually registered the Symbol's ext_type (so it
was always 0x0). This resulted in the optimization not working if Symbol
is registered with a different type and could additionally cause data
corruption if some other type is registered as 0x0.

Additionally, many of these Factory fields were not copied over on dup,
meaning pooled Factories would have optimized_symbol_parsing disabled if
they don't explicitly `freeze` before calling `pool` (which would do
`dup.freeze`).

Fix some Factory/ext_type optimization edge cases

Fix: #401

Packer_write_extension: guard on string being moved

Co-Authored-By: Jean Boussier <[email protected]>

Consume cached nil in Unpacker#skip_nil

…edge-cases

Fix Factory registration edge cases

A recursive extension proc that rescues an inner read error, or that
calls Unpacker#skip, drives stack.depth down to 0 before
read_raw_body_begin pops the barrier it pushed. The unconditional pop
then underflowed depth to SIZE_MAX and read/wrote out-of-bounds stack
entries, crashing the VM. Restore the depth to just below the pushed
barrier instead of decrementing unconditionally.

Co-Authored-By: Claude Opus 4.8 <[email protected]>

…flow

Fix SEGV on stack depth underflow in recursive extension unpacking

RubyHash#fastARef returns Java null for an absent key, so registering a
Symbol type with only an :unpacker raised NullPointerException.
ExtensionEntry.hasPacker already guards the same value this way.

Guard packerProc against a missing :packer key on JRuby