remove no_std hashbrown dep

[knickish]

Hashbrown added several recursive deps, time to rip it out

[not-fl3]

Fun fact: hashbrown now depends on syn and whatnot, which kind of eleminates the whole purpose of nanoserde

│   ├── hashbrown v0.13.2
│   │   └── ahash v0.8.11
│   │       ├── cfg-if v1.0.0
│   │       ├── once_cell v1.19.0
│   │       └── zerocopy v0.7.34
│   │           └── zerocopy-derive v0.7.34 (proc-macro)
│   │               ├── proc-macro2 v1.0.82
│   │               │   └── unicode-ident v1.0.12
│   │               ├── quote v1.0.36
│   │               │   └── proc-macro2 v1.0.82
│   │               │       └── unicode-ident v1.0.12
│   │               └── syn v2.0.63
│   │                   ├── proc-macro2 v1.0.82
│   │                   │   └── unicode-ident v1.0.12
│   │                   ├── quote v1.0.36
│   │                   │   └── proc-macro2 v1.0.82
│   │                   │       └── unicode-ident v1.0.12
│   │                   └── unicode-ident v1.0.12
│   │       [build-dependencies]
│   │       └── version_check v0.9.4

never trust a crates.io dependency, they can bring a full rust parser into your dependency tree at literally any moment :D

(not a no-std user here, no opinion on what to do about it)

[knickish]

Gah thats not cool. Hmmm. Maybe we should just drop hashmap impl when doing no_std?

[knickish]

I guess that wouldn't be additive though :/

[knickish]

@not-fl3 looks like that was optional, got it down to

cargo +nightly tree --features "no_std, binary"

nanoserde v0.2.0
├── hashbrown v0.14.5
│   └── ahash v0.8.11
│       ├── cfg-if v1.0.0
│       ├── once_cell v1.19.0
│       └── zerocopy v0.7.34
│       [build-dependencies]
│       └── version_check v0.9.4
└── nanoserde-derive v0.2.0 (proc-macro)

[not-fl3]

--target=all still got syn etc, and Cargo alwas downloads it now, even when no-std is off.

[not-fl3]

Actually, it was not the case for 0.12 (tho 0.12 use getrandom/wasi...)
Do we really need 0.14? Is it worth downloading 6 extra fairly heavy dependencies?

--target=all do happen on the CI and cargo downloads all those dependencies no matter what features are used, so I would rather not have hashbrown from now on at all to be honest, but I am not sure if this would be very easy to do

[knickish]

I guess it makes more sense to make a PR to add nanoserde support for their types in hashbrown itself at this point. They already have features for serde + rykv, so seems likely they would accept it

[knickish]

Alright, ripped it all out now and switched to a BTreeMap for the toml parser internal representation of arrays so that it can be used with no_std

[not-fl3]

Wow, such a clever solution, a huge fan of this PR! Somehow I totally overlooked that alloc got collections!

still totally usable with no_std and we still have std::HashMap support for jsons with std!

Looks super good to me!