add support for regexp routes

[jxskiss]

This pr adds support for regexp routes.
The discussion is here: #85

[jxskiss]

The PR code implements regexp support as following:

1. regexp routes can be registered after static, wildcard prefix
2. multiple regexp routes can be registered after a same prefix, they will be checked in their registering order
3. regexp routes with longer static or wildcard prefix takes higher priority than those with shorter prefix
4. named capturing groups will be passped to handler as params map
5. if a route is matched, but no handler is registered for the request method, for simplicity, the returned status code is 404 instead of 405 (not sure if we should support 405 for regexp routes)

[jxskiss]

@dmitris Hi, wish you have time to take a look at this, and feedback what do you think about it.

[dmitris]

@jxskiss honored by your request but to make sure - you didn't mean someone else (maybe @dimfeld), did you? 😄

[dimfeld]

Been very busy lately, hopefully will have time soon

[jxskiss]

@jxskiss honored by your request but to make sure - you didn't mean someone else (maybe @dimfeld), did you? 😄

Oh yes it's a typo, sorry to bother 😳

[dimfeld]

Apologies for the delay. A couple things seemed notable to me:

1. Right now the regexp matches on the entire remaining path, but it also seems desirable to have a regexp that only matches on a single path segment, such as /images3/~^(?P<timestamp>\d+)/:imageName. It feels like the single-path match should actually be the normal case here. What do you think?
2. It would be good to have this support the MethodNotFound error. This is basically the case where found is not nil, but handler is nil, and the code that calls search uses that condition to return MethodNotFound. You can see where this happens in the wildcard child code.

[jxskiss]

1. Right now the regexp matches on the entire remaining path, but it also seems desirable to have a regexp that only matches on a single path segment, such as /images3/~^(?P<timestamp>\d+)/:imageName. It feels like the single-path match should actually be the normal case here. What do you think?
2. It would be good to have this support the MethodNotFound error. This is basically the case where found is not nil, but handler is nil, and the code that calls search uses that condition to return MethodNotFound. You can see where this happens in the wildcard child code.

1. Though the pattern /images3/~^(?P<timestamp>\d+)/:imageName can also be easily written using regular expression and gives more flexibility, I agree with that single-path match should be a more normal case in url matching.
2. I'm ok to return the MethodNotFound error.

I will update the code.