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.