There are basically 2 big updates in this commit:

1) Split up each range type handler into a separate function
    (plus a few helper functions).
2) Export a type infer-er

The type infer-er is useful internally, but also helps me
feel more confident about code changes. In theory no 
type should ever collide with another type, so this 
function is kind of like the "canary in the coal mine" 
in that we should always be able to test a 1:1 range 
type from this function. If we can test the types 
thoroughly, we can be more confident each respective 
handler is working on the right set of data.

On that note, splitting up the logic for each range type 
makes me feel much more confident that each one is 
handled in a way that doesn't conflict with any other. 
More importantly, any potential changes to an existing 
range type or additions of new range types will: 
A) Not cause any changes to the existing ones and
B) Scale gracefully

On that final note of graceful scaling, I find the (very
common) method of basically extending a long 
if/else if/else block to be frightening from the 
perspective of ever needing to add things. I've found 
the method I use here (a dictionary lookup, in a bunch 
of cases) to be much easier to reason about: every 
addition adds a single dictionary entry, and the JS 
selects it (O(1)) when it's needed.