As we can only increase verbosity with commandline flags, we
should set the least verbose log level by default.

Tell at least, what level can be set.

When we set logging levels, then handlers must support this.

While it is nice to have a working plugin example, it looks also a bit
overcomplicated to me. It is better for contributors, if they can find
things (like CLI argument parsing) in one (foreseeable) place and do
not have for things scattered over the whole project.

For plugin documentation we can use the sphinx docs. Or maybe provide
a sample plugin in tests.

This argument makes sense together with ``realdice`` randomsource
and tells how many sides the dice we use have. Six by default.

The RealDiceRandomSource will support own commandline arguments. This
is handled by an own classmethod called `update_argparser` that is
called upon initialization of diceware.

If plugins want to work with their own commandline args, we allow
this by calling their `update_argparser` methods. This has to be a
classmethod, if it exists.

In config files we normally lookup a ``[diceware]`` section.

For plugins, however, it might be helpful to be able to parse also
other sections. Together with the new `defaults_dict` argument
they could implement their own set of options more easily.

We can now give a custom dict to use for defaults.

This is the first step to make `get_config_dict()` usable also
for plugins.

This commit fixes #23

Add the `string.strip()` function to the `get_config_dict()`, to remove
inverted commas around string values in the diceware.ini file.
The strip removes both `"` and `'`.
Add unit test to ensure the line:

    delimiter=" "

in the diceware.ini file is being parsed correctly as a space.

This commit fixes issue #21.
Change all occurences of the option `capitalize` to `caps` in
__init.py__.

Make the same change in the test_diceware.py.
Add a unit test that checks the output of main() after setting the
`caps = off` in the .diceware.ini.

Add a common place where components can write messages to. Any
userinterface can decide, what messages should be visible
(depending on their severity).

With one item in sequence we do not have to roll dice. This holds for
all sorts of dice.

The moved comment was at the wrong place.

I guess it is obvious, how the first if-clause works.

We can simply do the (cheap) modulo operation after each die role.

Use multiples of 4 as indent, shorten overlong lines and fix
other minor things to keep pep8-conformity.

Move the calculations out of the `pre_check()` function.
Also do smarter checks:
  - If len(sequence) == 1, we don't need any rolls. In this case, just
    return sequence[0]
  - If len(sequence) is a factor of dice_sides, we only need one roll
    along with the modulo operator.
  - For everything else, just require one extra roll, bringing it to a
    total of 2 rolls. This should remove a little bit of the edge bias
    introduced by the modulo
Run the `pre_check()` function after the calculations have been done.

For the unit tests:
  - remove the function `test_choice_len_too_short()`;
    we no longer have to raise an exception when the sequence length is
    too short.
  - Write new tests for the cases where `dice_sides = 6` and `len(sequence)`:
     - 1
     - 2,3
     - 4,5

Add an if to the pre_check that catches cases where there are less items
to choose from than sides on the die. If this is the case, we can still
pick items, but we have to use a modulo.
Pick the `num_rolls` so that the result generated after rolling is larger
 than `100*len(sequence)`.
The `pre_check()` function now has to return the modified `num_rolls` as
well as a boolean to indicate whether modulo needs to be applied on the
result.

Use `.asc` filename extension for signed wordlists.

also updated README

Fixes #16

Normally, it would be more concise to use the more declarative name.
"en_8k" tells, how many terms we find in this wordlist. But as the
wordlist names are used in the CLI and users will normally simply
look for a wordlist in their language, it can help to keep the name
of the "default" list for each language short.

We pick the 8K lists for "default" (and not the "original" 6^5
lists), because we assume that normally people will use diceware
without dice. Also most other sources of randomness will most
probably work on a 2^x basis rather than in 6^x (and therefore
have better use for 8k lists over other ones).

We do support configuration files from now on.