Issue enarx#32 describes a class of errors where `deserialize_str` (and `deserialize_bytes`) have match
expressions that fall through to an error when the `Text` (`Bytes`) lengths are longer than can fit
in the scratch array.

This patch works around that limitation by delegating to the corresponding allocating methods
`deserialize_string` (`deserialize_byte_buf`) in case the scratch space is too small.

This should address the issue even for types whose `Deserialize` visitor does not implement
`visit_string`, since the default implementation of that method delegates back to `visit_str` once
the fully-deserialized `String` is in hand.

This addition raises a question to me about the stance of the `ciborium` crate on `no_std`/`alloc`
support. This workaround depends on being able to use `String` and `Vec`, which rules out
`no_std`. But these allocating deserializers already exist in the code and don't appear to be
guarded by `cfg` directives, so I don't believe this patch changes the level of support provided for
these environments.

Issue enarx#32 describes a class of errors where `deserialize_str` (and `deserialize_bytes`) have match
expressions that fall through to an error when the `Text` (`Bytes`) lengths are longer than can fit
in the scratch array.

This patch works around that limitation by delegating to the corresponding allocating methods
`deserialize_string` (`deserialize_byte_buf`) in case the scratch space is too small.

This should address the issue even for types whose `Deserialize` visitor does not implement
`visit_string`, since the default implementation of that method delegates back to `visit_str` once
the fully-deserialized `String` is in hand.

This addition raises a question to me about the stance of the `ciborium` crate on `no_std`/`alloc`
support. This workaround depends on being able to use `String` and `Vec`, which rules out
`no_std`. But these allocating deserializers already exist in the code and don't appear to be
guarded by `cfg` directives, so I don't believe this patch changes the level of support provided for
these environments.

Issue enarx#32 describes a class of errors where `deserialize_str` (and `deserialize_bytes`) have match
expressions that fall through to an error when the `Text` (`Bytes`) lengths are longer than can fit
in the scratch array.

This patch works around that limitation by delegating to the corresponding allocating methods
`deserialize_string` (`deserialize_byte_buf`) in case the scratch space is too small.

This should address the issue even for types whose `Deserialize` visitor does not implement
`visit_string`, since the default implementation of that method delegates back to `visit_str` once
the fully-deserialized `String` is in hand.

This addition raises a question to me about the stance of the `ciborium` crate on `no_std`/`alloc`
support. This workaround depends on being able to use `String` and `Vec`, which rules out
`no_std`. But these allocating deserializers already exist in the code and don't appear to be
guarded by `cfg` directives, so I don't believe this patch changes the level of support provided for
these environments.

Issue enarx#32 describes a class of errors where `deserialize_str` (and `deserialize_bytes`) have match
expressions that fall through to an error when the `Text` (`Bytes`) lengths are longer than can fit
in the scratch array.

This patch works around that limitation by delegating to the corresponding allocating methods
`deserialize_string` (`deserialize_byte_buf`) in case the scratch space is too small.

This should address the issue even for types whose `Deserialize` visitor does not implement
`visit_string`, since the default implementation of that method delegates back to `visit_str` once
the fully-deserialized `String` is in hand.

This addition raises a question to me about the stance of the `ciborium` crate on `no_std`/`alloc`
support. This workaround depends on being able to use `String` and `Vec`, which rules out
`no_std`. But these allocating deserializers already exist in the code and don't appear to be
guarded by `cfg` directives, so I don't believe this patch changes the level of support provided for
these environments.

Issue enarx#32 describes a class of errors where `deserialize_str` (and `deserialize_bytes`) have match
expressions that fall through to an error when the `Text` (`Bytes`) lengths are longer than can fit
in the scratch array.

This patch works around that limitation by delegating to the corresponding allocating methods
`deserialize_string` (`deserialize_byte_buf`) in case the scratch space is too small.

This should address the issue even for types whose `Deserialize` visitor does not implement
`visit_string`, since the default implementation of that method delegates back to `visit_str` once
the fully-deserialized `String` is in hand.

This addition raises a question to me about the stance of the `ciborium` crate on `no_std`/`alloc`
support. This workaround depends on being able to use `String` and `Vec`, which rules out
`no_std`. But these allocating deserializers already exist in the code and don't appear to be
guarded by `cfg` directives, so I don't believe this patch changes the level of support provided for
these environments.

Adds regression tests for slightly-too-long string and byte sequence roundtripping.