Supporting no-std and no-alloc

[rjsberry]

Would you be interested in reviewing a PR that adds support for no-std + no-alloc? Currently either the std or alloc feature is necessary.

#606 introduced support for no-std + alloc. However, since the alloc feature is still required, it doesn't address users who cannot or prefer not to use an allocator. Allocators can introduce unpredictability in terms of execution times and runtime behavior, which is particularly undesirable for resource-constrained devices. In some cases development guidelines may prohibit allocation altogether. Arguably not be the best choice for an embedded device, JSON does appear in standardized protocols that may be mandated for qualified products.

Users are directed to use serde-json-core for JSON (de)serialization without the standard library via https://serde.rs/no-std.html. The serde and serde_json crates are widely adopted and trusted. I think it would greatly benefit the embedded ecosystem if users without access to the standard library and without an allocator could leverage the high-quality implementation of the official JSON crate from the Serde project. It's much easier to make a case for introducing a v1.x.x library with 150M downloads!

I think a few changes would be necessary for the specific no-std + no-alloc build:

1. Configurable recursion (first requested in Allow increasing recursion limit #334), but to support decreasing limit.
2. Simplify Error, perhaps just storing category/line/column.
3. Fixed capacity deserializer scratch that is also configurable to users as it will affect stack utilisation.

I believe this can be implemented with little maintenance overhead or any major API differences between build variants.

1 is important to configure/lower the maximum stack utilisation. The unbounded_depth feature already supports removing the limit, but there is not a mechanism to bound the depth to some configurable value. If no-std + no-alloc were to be supported this would also be closely related for target users.

For example, implementing 1 and 3 above via environment variables at compile time (perhaps also with an unstable feature) keeps the crate API identical across feature combinations. If relevant I suppose 1 could be implemented at runtime via a method on Deserializer instead.

If Error is changed for the no-std + no-alloc build the Debug and Display impls of would of course change, but generally speaking human readable errors would not be a priority for firmware. Simplifying the Error type removes the need to carry around some of the Box<str> variant errors for no-std + no-alloc. I think this is potentially the largest deviation.

If you'd be open to a PR I'd definitely like to implement this.