Move hashbrown behind no_std feature

[grovesNL]

Follow-up to #160 to gate hashbrown behind no_std by default

cc @notgull please let me know if this is problematic for some reason

[grovesNL]

Looks like this breaks no-default-features, I'll try to workaround that

[grovesNL]

Unfortunately I don't think we have a great way to do this with the current features, because no_std and std features would ideally be mutually exclusive but both features could be enabled or disabled at the same time. Maybe we could revisit if we ever change how these features are setup.

(I didn't notice that std was also a feature initially)

Related to rust-lang/cargo#2980

[grovesNL]

Thinking about this some more, building with no default features doesn't make sense because either no_std or std must be used. We should replace this with a CI step to check no_std. I'll update this PR to add a compile-time error if neither is specified.

[ids1024]

Having both an std and a no_std feature isn't ideal. It should be possible to use #cfg(not(feature = "std")), but enabling dependencies and features of dependencies when a feature is disabled won't really work...

So I guess requiring either std or no_std makes sense, though hopefully cargo can get some better solution to this sort of thing some day.

[grovesNL]

@ids1024 agreed, it would be great if we didn't need to have both. In case it isn't clear, both features already exist in cosmic-text, so this PR is just attempting to move hashbrown behind the no_std feature.