use our internal apply helpers everywhere

Thanks @jdalton for the suggestion. Provides a small but significant speed boost in `.bind()`, `.partial()` and `.partialConstructor()`. We still get our asses kicked by SpiderMonkey for prebound functions, but it's still faster than before:

#### V8
```
  Native .bind() vs fast.bind()
    ✓  Function::bind() x 832,970 ops/sec ±1.44% (85 runs sampled)
    ✓  fast.bind() x 7,142,465 ops/sec ±0.91% (93 runs sampled)
    ✓  fast.bind() v0.0.2 x 6,376,371 ops/sec ±1.14% (88 runs sampled)
    ✓  underscore.bind() x 528,686 ops/sec ±1.57% (80 runs sampled)
    ✓  lodash.bind() x 349,213 ops/sec ±2.10% (80 runs sampled)

    Result: fast.js is 757.47% faster than Function::bind().

  Native .bind() vs fast.bind() with prebound functions
    ✓  Function::bind() x 4,596,421 ops/sec ±1.05% (93 runs sampled)
    ✓  fast.bind() x 19,187,335 ops/sec ±0.97% (87 runs sampled)
    ✓  fast.bind() v0.0.2 x 13,930,265 ops/sec ±0.94% (89 runs sampled)
    ✓  underscore.bind() x 4,562,916 ops/sec ±0.95% (86 runs sampled)
    ✓  lodash.bind() x 4,860,192 ops/sec ±1.17% (87 runs sampled)

    Result: fast.js is 317.44% faster than Function::bind().

  Native .bind() vs fast.partial()
    ✓  Function::bind() x 841,061 ops/sec ±1.83% (80 runs sampled)
    ✓  fast.partial() x 8,674,420 ops/sec ±1.54% (93 runs sampled)
    ✓  fast.partial() v0.0.2 x 7,056,606 ops/sec ±1.43% (87 runs sampled)
    ✓  fast.partial() v0.0.0 x 6,806,520 ops/sec ±1.31% (87 runs sampled)
    ✓  underscore.partial() x 1,629,855 ops/sec ±1.49% (90 runs sampled)
    ✓  lodash.partial() x 329,820 ops/sec ±2.75% (69 runs sampled)

    Result: fast.js is 931.37% faster than Function::bind().

  Native .bind() vs fast.partial() with prebound functions
    ✓  Function::bind() x 4,362,196 ops/sec ±1.54% (91 runs sampled)
    ✓  fast.partial() x 18,008,835 ops/sec ±1.37% (73 runs sampled)
    ✓  fast.partial() v0.0.2 x 13,511,525 ops/sec ±1.40% (82 runs sampled)
    ✓  fast.partial() v0.0.0 x 13,379,174 ops/sec ±1.53% (78 runs sampled)
    ✓  underscore.partial() x 6,610,677 ops/sec ±1.25% (91 runs sampled)
    ✓  lodash.partial() x 4,630,166 ops/sec ±1.36% (87 runs sampled)

    Result: fast.js is 312.84% faster than Function::bind().

```
#### SpiderMonkey
```
  Native .bind() vs fast.bind()
    ✓  Function::bind() x 1,052,708 ops/sec ±3.17% (52 runs sampled)
    ✓  fast.bind() x 1,998,159 ops/sec ±2.90% (58 runs sampled)
    ✓  fast.bind() v0.0.2 x 850,026 ops/sec ±2.40% (63 runs sampled)
    ✓  underscore.bind() x 491,642 ops/sec ±3.26% (56 runs sampled)
    ✓  lodash.bind() x 255,096 ops/sec ±2.15% (62 runs sampled)

    Result: fast.js is 89.81% faster than Function::bind().

  Native .bind() vs fast.bind() with prebound functions
    ✓  Function::bind() x 75,606,163 ops/sec ±0.51% (68 runs sampled)
    ✓  fast.bind() x 9,952,095 ops/sec ±0.55% (67 runs sampled)
    ✓  fast.bind() v0.0.2 x 4,535,786 ops/sec ±1.13% (66 runs sampled)
    ✓  underscore.bind() x 74,498,853 ops/sec ±0.59% (67 runs sampled)
    ✓  lodash.bind() x 1,680,624 ops/sec ±2.38% (64 runs sampled)

    Result: fast.js is 86.84% slower than Function::bind().

  Native .bind() vs fast.partial()
    ✓  Function::bind() x 1,105,650 ops/sec ±3.08% (52 runs sampled)
    ✓  fast.partial() x 2,245,123 ops/sec ±3.01% (60 runs sampled)
    ✓  fast.partial() v0.0.2 x 917,150 ops/sec ±2.15% (64 runs sampled)
    ✓  fast.partial() v0.0.0 x 916,274 ops/sec ±2.28% (62 runs sampled)
    ✓  underscore.partial() x 818,945 ops/sec ±1.93% (60 runs sampled)
    ✓  lodash.partial() x 263,751 ops/sec ±2.30% (62 runs sampled)

    Result: fast.js is 103.06% faster than Function::bind().

  Native .bind() vs fast.partial() with prebound functions
    ✓  Function::bind() x 78,707,103 ops/sec ±0.33% (69 runs sampled)
    ✓  fast.partial() x 9,642,861 ops/sec ±0.43% (66 runs sampled)
    ✓  fast.partial() v0.0.2 x 4,203,013 ops/sec ±1.27% (40 runs sampled)
    ✓  fast.partial() v0.0.0 x 4,162,810 ops/sec ±0.82% (67 runs sampled)
    ✓  underscore.partial() x 3,163,519 ops/sec ±0.46% (68 runs sampled)
    ✓  lodash.partial() x 1,593,738 ops/sec ±2.59% (61 runs sampled)

    Result: fast.js is 87.75% slower than Function::bind().

```

fixes #49 
> When fast launched and got all the hacker news buzz, Lo-Dash was beating or on par with most of its methods. 

Luckily we kept all the changes in `test/history.js`, and we run those historical versions in the benchmarks, so you can easily test for yourself to see whether the `v0.0.0` ones are faster or slower on `$engineOfChoice`.

>  you lack consideration of context and prioritize micro-opts over all-else.

No, we're prioritising performance and optimising for the 99% use case. The whole problem here is that you're looking at this from a pretty defensive stand point - someone even called you out by name on HN which I think was unfortunate. I think you see the shortcuts taken here as "cheating", because we go off spec, aren't DRY in some cases etc. But *the whole point* is that we're not following the spec! We're not *trying* to be 100% compatible with native (underscore), or trying to be a better/faster underscore (Lo-Dash), or trying to implement pretty functional magic (ramda). We are trying to be *fast*. And with that come certain tradeoffs - like verbose and ugly *library* code to enable beautiful and clean *application* code.

> Another hundred thousand ops/sec on something that's already millions? Is that really a pay-off?

Well, maybe. Especially as the costs are so low - this is a *small* library and it will remain so. As library authors we don't actually know whether that's going to make a significant difference for someone else. Speed is a feature, it enables things that were not possible or prohibitively expensive or complicated before. In this case it could go faster, so now it's faster. I can't find a way to frame that as a negative, sorry.