Fix issue #23 
Thanks a lot, @dwcoder !

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 helps to recognize options as such.

The removed vars were not really used in tests.

This way it is easier to check if any certain option is covered
already.

Try to cover all possibilities of `caps` related options when calling
`handle_options()`.

The modifications undone here, in
`test_handle_options_considers_configfile()` could have gone into an
own test. Each single test should only test a clear minimum of
things.

This specific test checked, whether configiles are considered at
all. It was not its purpose to examine correct interpretation of
keywords in the .ini-file; only to see whether these keyword values
can be changed at all.

If we wanted a complete and strict checking also of values, we had at
least to check all possible keywords, including 'randomsource' and
'wordlist'. Instead we only check a boolean, int, and string type
keyword.

Therefore the change to `test_handle_options_considers_configfile()`
should have gone to another test.

But then, the added testing is not neccessary. We had a test already
that should have checked the 'caps' value properly. This test was done
wrong before and is now done correctly, thanks to @dwcoder .

I therefore removed the added test functionality.

Running `pep8` or `flake8` over `tests/` complained about this one
blank line.

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.

This `Sphinx` theme is not a hard dependency of the `Sphinx` package
any more.

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

It is passing and doing as expected.

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.