Allow setting of initialDate via options

This determines the default date and time that is selected on the widget
as the user browses through the levels.
Refactor code to different structure

Instead of using a MultiWidget with only a single widget, we refactor to
put the picker functionality in a Mixin class which can then be
inherited from, along with the desired widget type (DateTimeInput,
DateInput or TimeInput.)

This approach is used because we're not really creating a MultiWidget
but rather a specialised version of the normal Date/Time/DateTimeInput
widgets.

I think the advantages of the refactor are:

- We don't have to worry about extracting the values from the widgets.
- We don't have to decompress a value list.
- The localisation is handled entirely in the constructor with more
  comments about what is going on and relying on class level format
  specifiers and names to handle the differences between the different
  widget types
- The template strings use '%(name)s' style specifiers instead of a long
  ordered list of arguments.
- Almost all the datetime picker options are optional. You can include
  as many as you like and use numbers or strings for the ones which
  accept both. Strings are automatically quoted.
- There are more comments explaining what is going on.
Pass 'format' to the base class

As it does some adjustments in the base class depending on the value
rather than just being happy that self.format has already been set.
Understandable.
Fix template error

Missing an 's'
Fix variable name typo
Switch defaults to numbers instead of strings

The quoting functionality assumes that if we want them as numbers in the
javascript then we feed them to the Python dict as numbers, not strings.
Improve language handling

As explained in the comments we attempt to convert from Django's
'language_countryCode' format that comes from 'get_language' to the
two letter language code that the Javascript is expecting.

To smooth the transition we store the available languages from the
javascript files in a set and try to match one if we possibly can by
checking first the language_countryCode and then the language by
splitting the former on '-'.

For non-i18n code paths we just leave the language entry in the options
as is. Expecting the user to get it right from the Python end if they
want something other than the default 'en'.
add removed options, and adapt the boolean paramtert for javascript, autoclose true by default
update readme in according with the last refactor