Refactoring forecast spice

**Changes:**
- Namespaced CSS.
- Removed ID selectors in CSS and replaced them with classes. Updated JS references accordingly.
- Precached array lengths in JS for loops (along with other frequently referenced object member lookups) for a [performance improvement](http://stackoverflow.com/questions/6973942/is-optimizing-javascript-for-loops-really-necessary).
- More efficient temperature converter.
- Lots of other similar small JS optimizations.

**Other changes similar to my [last PR](https://github.com/duckduckgo/zeroclickinfo-spice/pull/1341):**
- Made code formatting consistent (now only follows one style for things like whitespace, quotes, etc).
- Refactored JS to use function statements rather than function expressions where possible. This has the following benefits:
  - This is the most readable way to obey the [onevar rule](http://wonko.com/post/try-to-use-one-var-statement-per-scope-in-javascript).
  - This will give a named function in a stack trace in the debugger rather than an anonymous function, which makes debugging easier.
  - There is a [small performance advantage](http://jsperf.com/fn-expression-vs-statement).

**Questions:**
- While everything seems to work in my testing, these changes are more extensive than the last PR I opened. Can anyone share a good list of test cases aside from things like "forecast tomorrow" and "forecast next week" etc?
- `forecast_icons.handlebars` currently prefetches two different graphics (for both the light and dark themes) for all users regardless of which theme is selected. I think it would be better to engineer a way of fetching only the graphics that are relevant to whichever theme the user has selected, but I don't think that's possible purely from within the spice code. Can anyone speak to that?
Let's update this to be a bit more canonical. We should wrap this all in a closure and then move any private function definitions outside of the `ddg_spice_forecast` definition where possible