Add support for passphrase API by extending SCellSeal construction API.
It is possible to add via Python's __new__ special method which may
return an instance of a diffrent class (typically, more appropriate
subclass). We introduce a SCellSealPassphrase subclass with the same API
but different implementation of "encrypt" and "decrypt" methods.

To make things easier we also add a SecureCellError to provide more
contexts in exceptions without making error messages too long.

Initially a different syntax was planned:

    SCellSeal.with_passphrase('a secret')

    SCellSeal.with_key(binary_master_key)

It had a noble idea of maintaining similarity with other languages which
do not have named arguments. However, after updating tests and examples
this syntax came off as unnatural and non-Pythonic.

Those are mostly straighforward. Also, update existing tests for master
key API and ensure that positional arguments to Secure Cell constuctors
are interpreted as keys, not passphrases.

Another change is update of tests to use a proper master key instead of
a fixed password with master key API.

The main showcase has been reworked completely to demonstrate API.
Other examples got cosmetic updates to avoid using 'passwords' when in
fact they work with master keys.

Instead of forcing the users to do '.encode(...)' calls themselves,
adhere to standard Python practice of accepting an "encoding" argument
with specified default encoding.

Instead of writing type hacks, use a compatibility library. This should
make it easier to convert PyThemis into Python 3-only when we decide to
drop Python 2 compatibility. We will need to replace all "six" calls
with native equivalents.

Raise warnings instead of exceptions when we suspect that master key API
is misused with strings. Since we're not introducing a new API, it would
be rude to break Existing Code with unannounced exceptions. Howerver, we
cannot pass on the possible misuse either.

Master key API should not be used with strings. Currently, if you pass a
Unicode string, it will be encoded in some internal encoding (usually
UTF-8, but this may not be the case on Windows). Master key API should
not be used with human-readable strings due to security concerns.

Produce a warning when we see master key API to be used with types that
we previously allowed but no longer recommend. Provide suggestions on
what API should be used instead.

This warns the user of possible misuse (if they pay attention to
warnings) and does not break production code, which will keep the old
behavior of misusing strings as master keys.