Allow theme entries to be lists that are then iterated. For this
purpose, extend the Config class so that it can serve as generic store
for data items. That makes it easy to centralize code used for rotation
etc. in a single place.
Add functionality to provide lists of values for individual elements of
a theme (e.g. the prefix) and those will be cycled for each call.
This can be used, for example, to show a "charging" symbol for the
battery that continuously goes throw all the battery stages to "animate"
the charging icon.
Font and background colors for warning and critical elements can now be
specified using fg-warning, fg-critical, bg-warning and bg-critical.
Also, optionally, the "urgent" flag will be set towards the i3bar, if
possible.
It is now possible to add a list of theme configurations in the
"default" section called "cycle". These configuration items will be
cycled through module by module. to create "alternate style" effects.
This is *only* possible in the "default" configuration part, but any
module-specific configurations still take precedence.
Also, removed the capability of per-widget themes. That simply
complicates things and probably doesn't really bring any benefits.
Add the possibility to configure custom separators in the theme file.
These will only be used if the default i3bar separators have been
disabled. Background color will always be taken from the previous
element (to work nicely with my long-term plan, a powerline-like status
line).
Module themes (only!) can now contain state-specific theme information -
for example, the "battery" module has different states for charging and
discharging, and those can have different prefix and postfix
configurations to indicate what is going on.
Individual items in the bar can now be configured with a prefix and a
suffix. It works like this:
* If there is a specific module configuration in the theme
configuration, use that (i.e. { "<modulename>": { "prefix: " a " } })
* Otherwise, if there is a configuration in the "default" section of the
theme, use that
* Otherwise, if the module object itself has a method called like the
required attribute (prefix, suffix), use that
* Otherwise, leave prefix/suffix empty ("")
