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?
This can be removed, it's pretty old. Might as well remove the above comments as well, we can always get it back with git if need be