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

[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"