Take a peek at the test modules in both lib.rs and iter.rs. They contain key invariants to reading and
understanding what's going on when especially where the code starts into ```transmute```ing things.
There exist two section in the code, one in iter.rs and one in lib.rs bookended by ```// JANK```
comments. These represent the two most janky pieces of code and are the only hard dependencies on the
jank.rs module. Essentially we're making use of the open source nature of the Rust standard library to
mirror the definition of ```slice::Iter``` and transmuting it into a type where we can see the fields.
This was done to save space and make our code generic enough to actually have the desired effect of
"hiding" the plurality of a given type from the implementation. This however has the consequence of
making the code possibly a lot less portable and removes any chance of it being future-proof. Depending
on any number of factors which effect memory layout from platform to compiler version this code might
just plain old break depending on where you take it.
The only potential answer I see would be to make my own PluralizeIter type which would effectively just
be a byte-for-byte copy of the standard slice::Iter definition and itself would add nothing of value