Update: refactor tokens API (refs #1212)

This is a second attempt at the changes to the tokens API that had to be reverted a while back. It's a from-scratch rewrite, without looking at any of the old code.

It splits all of the token handling out of the core and into a new `TokenStore` class. This also greatly simplifies the token-handling tests.

Rather than searching linearly through ranges until hitting upon a matching token, `TokenStore` indexes based on the start and end of every token. This greatly simplifies logic inside of the API methods and improves performance because every token is accessible directly, no searching required. Furthermore, because tokens are still stored in the original array, there's no traversal required to reconstruct a contiguous array from the sparse array that was used before; all that's required is a call to `slice`.

Now for the performance data. All of this was obtained on a MacBook Pro with a 2nd-generation i7 running OS X Yosemite. Last time there was a performance regression on at least one machine, so help testing this on a variety of configurations is appreciated.

```sh
$ git co master && npm run perf

CPU Speed is 2200 with multiplier 7500000
Performance Run #1:  1499.543745ms
Performance Run #2:  1489.026796ms
Performance Run #3:  1489.335957ms
Performance Run #4:  1493.5138259999999ms
Performance Run #5:  1480.386587ms
Performance budget ok:  1489.335957ms (limit: 3409.090909090909ms)

$ git co token-store && npm run perf

CPU Speed is 2200 with multiplier 7500000
Performance Run #1:  1404.387172ms
Performance Run #2:  1366.972328ms
Performance Run #3:  1364.019312ms
Performance Run #4:  1369.947872ms
Performance Run #5:  1353.955682ms
Performance budget ok:  1366.972328ms (limit: 3409.090909090909ms)
```

I created a custom config to enable only the rules that call the tokens API, and the performance difference in some of the rules between master (time 1) and this PR (time 2) is significant:

Rule              | Time 1 (ms) | Time 2 (ms) | Difference
:-----------------|------------:|------------:|----------:
no-extra-parens   |     115.493 |     102.774 |    -11%
no-multi-spaces   |      54.537 |      43.220 |    -21%
no-spaced-func    |      53.051 |      24.109 |    -55%
space-in-brackets |      46.095 |      16.625 |    -64%
space-infix-ops   |      27.661 |      24.942 |     -9.8%
no-empty-class    |      26.492 |      14.497 |    -45%
no-div-regex      |      19.175 |      18.509 |     -3.4%
brace-style       |      18.792 |      18.292 |     -2.7%
semi              |      17.413 |         n/a |      n/a
no-regex-spaces   |      15.793 |      14.131 |    -11%
wrap-regex        |         n/a |      14.940 |      n/a

*Edit: I tested this on an Ubuntu VM in Azure that I happen to have handy, and the performance results showed improvement there too: 5499.9859ms on `master`, dropping to 5237.867ms for this PR.*

*Edit 2: One more change, just a tiny bit faster.*
I always just guess on JSDoc types. Looks like they seem to prefer lowercase primitives like `number`, `string`, or `boolean` in their [`@type` docs](http://usejsdoc.org/tags-type.html). Does `number` work?