Monthly adjust

This pull request is for the following changes:
- Add fixed monthly adjustment capability. Friends of mine tell me this works great for them, and they had mixed result with weatherunderground (I am not so happy either). opensprinkler_pi also has this capability. My twist is that one may decide on a different set of monthly adjustments per zone, or just define a default, or any mix of these two modes. Sorry, no documentation yet. See config-template.json for an example ("sand" refers to the type of soil, which impacts the watering adjustment).
- Fixed a few refresh issues with weather and calendar, optimize the event display (don't request all events periodically: just check the latest one) to avoid growing CPU overhead as the history gets longer, add more information for monitoring adjustments and cleanup the web client code in the process. These changes are to stabilize the software that is currently running.
- Web look-and-feel redesign (heavy use of CSS).
- Start the development of a web page to edit the configuration. For now, the input fields are populated but no code to commit the changes back. In order to make the GUI easier on me, changed the format of  programs (compatibility warning: format of days array is now an array of exactly 7 Boolean values and a new "repeat" field is now mandatory).
- Add an option to get an evapotranspiration watering index from an external web site (waterdex for now). I am quite happy with this one: compared to the opensprinkler_pi index (even after adjustments) this is more sound and less extreme. Waterdex however provides an index significantly lower than bewaterwise.com. Hummm.. That might be because the waterdex dial tops at 100% (by design), while controllers adjustment typically can go up to 150%.
- Add per-zone options for pulsed watering, i.e. cut the watering of the zone in a number of runs depending on a maximum run time (pulse), with a pause in between. For example, if a zone is defined with a pulse of 2 mn and a pause of 30 seconds, watering it for 5 mn will cause the zone to be active 3 times. The goal is to avoid runoffs if the watering is absorbed more slowly than is delivered. Because the recommended pause is typically long (1 hour), the software optimizes the pause by doing the pulse for each zone, then follow the longest pause, run the zones that remain to be run, follow the longest remaining pause, etc. This is repeated until there is no zone left to run. This is functionally equivalent to programming multiple start times in commercial controllers, except that the user does not need to bother himself with this in each program: he defines the pulse/pause once for each zone, create a program with the total runtime and sprinkler figures out itself how many times it needs to repeat the program.