Support non-str values in a Rodeo

[CraftSpider]

Adds a new public trait, Internable, which is by default implemented for str, OsStr, Path, and [u8]. This is a noticeably breaking change, due to the addition of a V generic on most things, as well as regressions for a couple type-inference locations.

I can add in #26 now if desired, as this seems a good time to make that change, if breaking inference anyways.

fixes #23

[CraftSpider]

Intentionally public, though should maybe be an unsafe trait, as implementations are expected to round-trip correctly.

[CraftSpider]

Rust intentionally doesn't allow you to get an OsStr as bytes cross-platform

[CraftSpider]

Swapped because JSON requires hashmap keys be strings, and that would require escaping/unescaping complexity

[Kixiron]

I'd rather let the deserializer manage things themselves, there's a lot more formats than json

[CraftSpider]

Fair enough, though also, at least with this ordering it's less likely to break a lot of use cases. The tests use JSON, so I figured keeping it working would be considered more important than simply swapping the position here. Would you rather I swapped it back anyways?

[Kixiron]

I did some work on this in my internable branch and I've got a few issues:

• We can't assume that all internable types play nicely as byte slices. I attempted to implement a windows OsStr Internable implementation but was quickly beaten down by the lack of an allocation-less api for recovering an OsStr from anything, OsString::from_wide() requires allocating which totally defeats the purpose of anything we do. OsStr::encode_wide() is less than ideal but it's totally doable, we just have to align our byte slices to 2 instead of 1, but it's pointless when any conversion back from our stored wide strings to an OsStr requires allocation. rust/#95290 could hypothetically help us, but I honestly don't have a lot of hope it's getting implemented any time soon. I'm pretty sure that the issue with OsStr on windows was the reason I initially gave up on generalizing interned types and the situation unfortunately hasn't changed from then.
• Serialization & deserialization with arbitrary types is really complicated once you give up the assumption that every internable type must be a u8 slice
• Placing the value type as the second type parameter is hugely breaking and breaks in really confusing ways since currently the second type parameter is the hasher. It's fairly unavoidable that this PR breaks all previous usages, but I don't like how incredibly confusing it is when that happens

In my branch I pretty much just give up on the first two problems, I use OsStr::to_str().unwrap() and only implement Serialize/Deserialize for Rodeo<K, str, S> but I'm not a fan of either "solution"

[rlabrecque]

Do you know if this helps solve the problem with OsStr?

rust-lang/rust#109698

[rlabrecque]

FWIW here's this branch rebased on top of master: https://github.com/rlabrecque/lasso/tree/rlabrecque/internable

Seems to work really well for my needs so far.

[cactusdualcore]

In my branch I pretty much just give up on the first two problems, I use OsStr::to_str().unwrap() and only implement Serialize/Deserialize for Rodeo<K, str, S> but I'm not a fan of either "solution"

Personally, I'd rather have an imperfect and unstable API for this now than have a perfect API in two years.
I'd suggest any fixes that can be done reasonably fast, then merging this into the mainline as an unstable API (i.e. changes to do NOT need a semver major version bump) behind an explicit feature flag.

This gives anybody who needs this functionality now something to at least work with, while making all of the downsides non-commital.

(If OsStr cannot be natively interned, it can always be turned into a &[u8] by the user through OsStr::as_encoded_byte).