Handle symbol dumping properly

[headius]

This PR is for #5523. In that issue, we found that the order a symbol and its encoding are being registered are correct, but when unmarshaling the symbol we register the encoding first. This led to the actual symbol content being treated as the encoding key, and the encoding value became the hash value associated to the original symbol. Then everything was off by one.

There's an issue here, though, in that the symbol is created and registered with our internal tables before its encoding is set correctly. This is also how MRI works, but they don't have issues for obvious reasons.

[headius]

The one failure appears to be related to #5520 and not anything in this PR.

[headius]

Additional work brought about by @enebo realizing the previous logic could potentially change the encoding of an existing symbol. I added a new newSymbol path that accepts a "handler" lambda, called with the existing symbol + false (not a new symbol) or the new symbol + true (new symbol) before storage into the symbol table. This avoids both modifying an existing symbol's encoding and allows us to register the symbol link before setting the encoding.

[headius]

I believe @enebo approves.