Add "index" field to keys to account for extra wildcard groups

[chrisinajar]

As per expressjs/express#2617 when you use a * as a wildcard in a path it'll generate a (.*) which creates an extra match group when you run the regular expression. The index value allows you to to account for this in consuming code in an API compatible way.

I think that in future API breaking versions, wildcard groups should probably be full on keys with some metadata.

[blakeembrey]

Looks like a nifty workaround. My first thought is that we can splice the keys into the resulting keys array to avoid requiring changes to other libraries still on 0.1. In both cases I think this breaks some level of backward compatibility, but I need to think on it more (E.g. /*/:foo/(\\d+) is now different - both will conflict on index zero). You might need to increment n++ in expressjs/express#2637 at the same time.

[chrisinajar]

The conditional I put on the express side doesn't continue; the existing n++ should still run.

The only difference in the example you gave are two new values on the existing key, index and _offset (which could be deleted). Typical consuming code, although I can only speak for the way express uses it, wont care about the extra values on the object. It seems like the most important part to that code was the number of them in the array.

Do you have any suggestions that would help it get merged in? I'm especially interested because of the express bug which depends on it.

[blakeembrey]

It should be easy enough to merge in, especially to 0.1. I just need to look over and test it a bit more, probably a little later tonight. Would you mind adding a note to the README.md about this too? Just a quick why and how.