Performance tests

**Goal**

Test the performance impact of fixes/changes. So, we ensure our performance is continuously improved; In other words, we're interested in comparing how fixes or changes affect the systemic performance of the library.

**General Ideas**
- We need to compare the performance before and after a change. Therefore, we need a metric describing how fast Globalize performs what it's supposed to.
- We're interested in the systemic performance of the library. Therefore, performance tests `performance/*` should use the built files `dist/*` (and public methods `Globalize.*`), analogous to the functional tests `test/functional/*`.
- Keep it simple. The performance tests are about generating the performance metrics (benchmark). A second and different problem is about comparing two different results. For this one, consider something analogous to https://github.com/rwaldron/grunt-compare-size.

**Workload**
- We need to define that. It should reflect what Globalize applications look like.
- Vyacheslav Egorov [talks about shitty workloads](https://www.youtube.com/watch?v=65-RbBwZQdU) you should avoid.

**References**
- [How do you performance test JavaScript code?](http://stackoverflow.com/questions/111368/how-do-you-performance-test-javascript-code/24149815#24149815)
- https://github.com/jquery/sizzle/tree/master/speed
- https://github.com/rwaldron/grunt-compare-size
- http://benchmarkjs.com/
- https://www.youtube.com/watch?v=65-RbBwZQdU