Regardless of if you want to take me up on the following challenge, if you have need for a
`split_quad`, `split_quint` etc. sharding, implement it and I'll merge everything and update quite
quickly. I myself am actively developing using this utility as of Sept 2019.
If you wish to contribute to this project and are interested in dynamic code generation, boy do I have
a (hopefully not too daunting) challenge for you. Currently `Shard`s are split statically through the
`split_tuple` and `split_triple` functions. I don't need a `split_quadruple` so I'm not writing it out
by hand. Nonetheless it's pretty obvious that dynamically creating a `split_N` interface for
arbitrarily sharding would be almost ideal and would serve to futureproof the crate.
Your mission if you choose to accept it: There are obvious hurdles between the current implementation
and a dynamically generated `split_N` type interface, namely type parameters are a pain. Writing out 4,
5, 6 distinct type parameters really adds up. My initial thought was to use a `macro_rules!()` taking
an N parameter and the Shard to dynamically generate the _interface_ up to N splits. I'm not terribly
practiced with macros, but that would be my starting point if I were to revisit the problem.