feat: Make allocations when decoding fallible

[ParkMyCar]

This PR makes any allocations that occur in the decode path fallible, without any public API changes.

The changes are specifically scoped to repeated fields, Vec<u8>, and String.

• Repeated fields, before pushing onto the Vec<...> of values, we now call Vec::try_reserve(1) and map the possible TryReserveError to a DecodeError. Reserving for a single element is what Vec already does so there shouldn't be a performance impact, and DecodeError is already opaque so this doesn't change the public API surface.
• Vec<u8> and String, these types reserve space as part of the sealed::BytesAdapter::repliace_with trait. This trait method was updated to return a Result<(), TryReserveError> and now will fail if we can't reserve enough space. Given this is a sealed trait there are no public API changes.

In addition to making allocations fallible, I also changed the merge impl of Vec<u8> to use bytes::merge_one_copy like String does, this should result in strictly less allocations.

Why make this change?

Previously users had no way to guard against OOMs in decoding. You could try to make a guess based on the size of the encoded message, but this fairly inaccurate because it would be very difficult (impossible?) to account for things like the ammortized growth of a Vec. Even if you did guess based on the size of the encoded message, there is no way you could account for multiple messages being decoded in parallel in individual tasks, e.g. handling multiple network requests in parallel.

What about the encoding path?

A similar change is not needed for the encoding path because you can already guard against OOMs by using the encoded_len() to allocate a buffer yourself guarding against OOMs, and then encode into this newly allocated buffer.

[caspermeijn]

While I don't need this myself, I am open to supporting this. However, the current PR is not maintainable over the long term, as it doesn't prove that all allocations are fallible. To ease the work of the maintainer, the test suite should fail if an infallible allocation is added in the future.

Please add a test that proves the guarantee that decoding will not crash due to memory scarcity.