DST and leap year fix

Hi,

We had two problems with the computation of the ranges in the RangeAggregator:
- it does not take **DST** into account. Example: when computing day aggregations over the year, the day range is from 0am to 0am in winter and from 1am to 1am in summer. 
- it does not take **leap years** into account.

## Getting the time zone
In order to fix for DST, I needed the timezone of the user so
- I added a timezone field in webroot/index.html
- I modified the functions in  webroot/js/kairosdb.js and webroot/js/kairosdb.js to deal with the timezone field
- I added a DateTimeZoneDeserializer in GsonParser
- I added a field timezone in core/datastore/Sampling

If no timezone is specified, the time zone of the machine will be used (just like in previous versions).

## Fixing range computation
All range computation are done with jodatime. To avoid dealing with TimeUnit throughout the code of RangeDataPointAggregator, I extract the DateTimeProperty corresponding to the TimeUnit in the  constructor. When I compute the start and end of the ranges, I only use DateTimeProperties forgetting about the TimeUnit and their special cases.

Jodatime deals with dst, leap years, month arithmetics for us.

Additionally, the sampling is not aligned anymore to the beginning of weeks, month or year when using a unit of respectively, week, month or year (It allows to compute aggregation wednesdays to wednesday, etc).

## Unit tests
Added unit tests in the range aggregator:
- test_dstMarch
- test_dstOctober
- test_februaryRange
- test_leapYears

*This is my first pull request, any advice is welcome* :)
Ok, I understand your point but I think this "jumping problem" is the client's problem, not the aggregator's problem. It would be easier to reason about the queries if the behavior was consistent across units.

But I can change it nevertheless, should I? :-)