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 
> Sure, but a week ago Lo-Dash etc did not particularly excel in these areas, it's great that you're changing that.

Lo-Dash has had custom builds for a couple years now and modularized builds since last fall.

> Aside from (presumably) the case you commented on here, can you point to any other cases you consider "micro optimizations", just so that I'm clear about what you're referring to.

Micro opts are things like [this](https://github.com/codemix/fast.js/blob/2871d3924fe7ea181593f06ce1cafbd9f234bde8/lib/index.js#L517) and [this](https://github.com/codemix/fast.js/blob/2871d3924fe7ea181593f06ce1cafbd9f234bde8/lib/index.js#L545), separating [this](https://github.com/codemix/fast.js/blob/2871d3924fe7ea181593f06ce1cafbd9f234bde8/lib/index.js#L574) & [this](https://github.com/codemix/fast.js/blob/2871d3924fe7ea181593f06ce1cafbd9f234bde8/lib/index.js#L584), avoiding initial values `undefined` in [this](https://github.com/codemix/fast.js/blob/2871d3924fe7ea181593f06ce1cafbd9f234bde8/lib/index.js#L305), not handling `fromIndex` cases in [this](https://github.com/codemix/fast.js/blob/2871d3924fe7ea181593f06ce1cafbd9f234bde8/lib/index.js#L443), and also things like [this](https://github.com/codemix/fast.js/blob/2871d3924fe7ea181593f06ce1cafbd9f234bde8/lib/index.js#L43). You're fixated on relatively insignificant performance wins at the sacrifice of clarify, features, & functionality. You can beat native without going into the realm of micro-opts.

> This case I think is pretty clear, it's about doing less work for each bound function invocation, so the bound function goes measurably faster.

There are hints of good principles in your work. Optimizing for the common case is a good thing, avoiding extraneous work is a good thing, but throwing another thousand ops/sec onto something that is already millions of ops/sec falls into the micro-optimization bucket.

> No, I would not do this in any other project unless it really mattered.

It doesn't really matter, not for `fast.js` or most anyone else. I'll repeat, you're fixated on relatively insignificant performance wins at the sacrifice of clarify, features, & functionality.