Build time regression from the Compound type

[kvark]

... introduced in #206
According to #206 (comment), results in 13% increase in IR size.
We want multiple parts of Gecko to ship (at least on Nightly) with RON built-in and enabled, so code size is important: we want that path to be as light as possible.
cc @nnethercote @Plecra

[Plecra]

I hope we can start with assessing the actual impact - the number of instantiations haven't changed, and LLVM just seems to be reporting 3x the IR size in each function. This doesn't directly reflect the final code size or the compile time (which I'm assuming is what we really care about)

[nnethercote]

LLVM IR size has proven to be a good proxy for compile times, particularly for debug builds. See rust-lang/rust#72013 for one example. But it would certainly be worthwhile for you to check that this observation holds for this case as well.

[nnethercote]

This is the likely cause of an installer size increase for Firefox when Firefox updated to 0.6.2.

[kvark]

@nnethercote looks like bincode-1.3 was able to address it on their side, but I'm not able to find the exact change/PR on a cursory look.

[juntyr]

During deserialization we read in and buffer all bytes. Could we do something similar and revert to appending to a String in the Deserializer, which is only flushed to a writer at the end? This would reduce most of the duplication at the cost of not supporting extremely large RON documents.