Library implementation for pattern matching

[Idan Arye via Digitalmars-d]

While getting a bit carried away with my 
`castSwitch`(https://github.com/D-Programming-Language/phobos/pull/1266#issuecomment-53218941), 
I realized I can do more - much more - if I can create a 
"Constraint" struct, one that can limit the values it can receive 
based on it's template parameters, and that can be queried to 
verify if a value fits in those limits without relying on 
exceptions. That kind of struct will allow me mimic the 
concrete-values-in-pattern and the case guards that you can often 
see in (statically typed) functional languages.

Even with that function, I believe there is still room for the 
old `predSwitch`, `castSwitch` and `regexSwitch`:

`predSwitch`(https://github.com/D-Programming-Language/phobos/pull/1259) 
is a syntax optimization for when you don't care about the 
matched object, only which case matched.

`regexSwitch`(https://github.com/D-Programming-Language/phobos/pull/1392) 
provides simple string-to-value conversions and in the future 
will hopefully provide range-of-matches iteration(which will make 
it a mini-lexer)(the requirements for it to provide this are what 
currently block that PR, but that's OT).

`castSwitch`(https://github.com/D-Programming-Language/phobos/pull/1266#issuecomment-53218941) 
provides an optimization that skips many failed casts - that 
optimization takes up the majority of the code, and it will 
become so much more complex(and IMO infeasible) once we add the 
`Constraint` support, so I would rather leave it out of the 
super-powered pattern matching function and leave `castSwitch` as 
is.


So, after I finish adding multiple arguments support to 
`castSwitch` I want to start coding that full blown pattern 
matching function. Right now I consider two options:


1) First create the Constraint struct as a PR to `std.typecons` - 
that kind of struct might be useful for other things as 
well(think argument verification for reflective dispatch 
frameworks). After that gets accepted, create the monster pattern 
matching function as a PR to `std.algorithm`.

2) Create a third party library and make it available on DUB. 
Have that library closely follow the Phobos coding standards so 
someday we might add it as a new module.


The first option will allow it to get into the standard library 
faster, but the second will make it available faster and allow me 
to experiment more so I'm tending to choose it. If I follow that 
second path - do we have a convention for naming third party 
packages that aim to get into Phobos? Should I name it 
`stdx.patternmaching` or `std.experimental.patternmatching` or 
something?


Any opinions?