The Werkzeug reloader is disabled by default due to a bug with
using it in combination with `python -m mutalyzer.entrypoints.website`.

https://github.com/mitsuhiko/werkzeug/issues/461#issuecomment-139369694

By default, the first request to the SOAP service will trigger a
build of the WSDL document, using the context (service location)
from that request. For example, if the first request is on
`http://localhost/` and subsequent requests are on
`https://mutalyzer.nl/services/`, they will not have a valid WSDL
document.

This is actually what we do on our production infrastructure,
where the service is tested (on localhost) after it has been
started.

The fix is to force a build of the WSDL document and specifying
the location to use.

http://spyne.io/docs/2.10/reference/server.html#spyne.server.wsgi.WsgiApplication

Issue #50 showed a problem in our file encoding detection, caused
by our cut-off for the confidence as reported by the cchardet [1]
library:

    >>> import cchardet
    >>> s = u'NM_000052.4:c.2407\u20132A>G'
    >>> b = s.encode('WINDOWS-1252')
    >>> cchardet.detect(b)
    {'confidence': 0.5, 'encoding': u'WINDOWS-1252'}

We require a confidence stictly greater than 0.5 and default to
UTF8 otherwise.

If, however, we try the same thing using the chardet [2] library,
we get a higher confidence for the same string:

    >>> import chardet
    >>> chardet.detect(b)
    {'confidence': 0.73, 'encoding': 'windows-1252'}

So the two obvious ways to solve this are:

1. Lower the confidence threshold.
2. Use chardet instead of cchardet.

We implement the second solution here, since it also removes a C
library dependency and we are not worried by performance.

Of course the detected encoding remains a guess which can still
be wrong!

[1] https://github.com/PyYoshi/cChardet
[2] https://github.com/chardet/chardet

Fixes #50

This is a work in progress as there still seem to be some bugs. For example,
some unit tests fail due to incorrect descriptions generated and others fail
due to a crash.

We use a separate `doc/requirements.txt` file for building the
documentation. Since on Read The Docs where we cannot install
packages depending on C libraries, we mock these packages in
`doc/conf.py` and omit them from the requirements.

Last remaining relevant todo notes have been filed as issues in GitLab.

See http://pytest.org/

Based on comments by Jeroen in issue #14.

See http://semver.org/

This is quite a large commit, touching many things related to developer
documentation. It is all focussed on getting as much of this as possible
into the new Sphinx-based documentation.

Some highlights:

- Start Sphinx-based developer documentation, including fairly complete
  instructions for installation and configuration.
- Remove epydoc API docs.
- Rework some docstrings to conform to reStructuredText, so they can be
  used in the API docs generated by Sphinx.
- Move all of the top-level text files to reStructuredText so they can
  linked from the Sphinx-based docs and for consistency.
- Remove many obsolete things from the extras/ directory, including old
  installation scripts and migrations.

Many of the installation related documentation and scripts are removed
or adapted in light of the new automated deployment using Ansible.

The paper (from `Mutalyzer 2.0/`) is now in the `mutalyzer-manuscript`
repository, while all presentations, posters and abstracts are now in
the `mutalyzer-presentations` repository.

git-svn-id: https://humgenprojects.lumc.nl/svn/mutalyzer/trunk@697 eb6bd6ab-9ccd-42b9-aceb-e2899b4a52f1

git-svn-id: https://humgenprojects.lumc.nl/svn/mutalyzer/trunk@688 eb6bd6ab-9ccd-42b9-aceb-e2899b4a52f1

git-svn-id: https://humgenprojects.lumc.nl/svn/mutalyzer/trunk@660 eb6bd6ab-9ccd-42b9-aceb-e2899b4a52f1

git-svn-id: https://humgenprojects.lumc.nl/svn/mutalyzer/trunk@646 eb6bd6ab-9ccd-42b9-aceb-e2899b4a52f1

git-svn-id: https://humgenprojects.lumc.nl/svn/mutalyzer/trunk@645 eb6bd6ab-9ccd-42b9-aceb-e2899b4a52f1

git-svn-id: https://humgenprojects.lumc.nl/svn/mutalyzer/trunk@622 eb6bd6ab-9ccd-42b9-aceb-e2899b4a52f1