Our new, better frequency is not ready yet (see issue #11), and many
users have built some muscle memory from their years of typing
Cangjie/Quick on that other Operating System.
Let's use that older, worse ordering for now, and we'll see later on how
to introduce the new one.

IBus Cangjie is not really a library, so the going with LGPL instead
of plain GPL doesn't make much sense in retrospect.
I asked Benau (the only contributor other than myself) and he agreed
in an email.
So all copyright holders agreed, and from now on, IBus Cangjie is
distributed under the GPLv3+.

It came to my attention that pycanberra is LGPLv2 only, while IBus
Cangjie is LGPLv3+.
The mix of the two, bundled together might be problematic, so to avoid
any issue, dropping our copy of pycanberra is the easiest way out.
The code was already handling errors to play sound anyway (no sound
would be played, so let's generalize that to the case where pycanberra
is just not available.

Commit 07c6055d introduced a fix for issue #22, so that we now
automatically clear the current input on a user mistake.
This commit just makes sure we actually always do that.
Specifically, we were missing the case where we had already reached the
maximum input length.
This commit also adds a unit test, to make sure we do not regress in the
future.

IBus 1.5.x introduced some very nice GI overrides for its classes, which
make the API much more Python-friendly.
I had refrained from using them though, because I wanted to keep the
compatibility with Python 1.4.2 as it is still used on (at least) Ubuntu
13.04 and Debian Sid.
However, when I worked on the IBus.Property stuff, I didn't pay enough
attention and used the overridden constructor, which doesn't exist on
IBus 1.4.2.
This fixes issue #23.

Playing an error sound is a great way to provide feedback to the user
when they make a mistake.
However, it might fail (e.g bug in the sound stack, or due to the
fragility of pycanberra), and it must not crash the engine.

In Cangjie, the asterisk (*) can only be used as a wildcard if it is
**surrounded** by text, that is, it needs **at least** one character
before and one character after.
As such, if the first thing the user types is an asterisk, we shouldn't
consider it as a wildcard, but as a plain character to type directly.
This commit introduces two new unit tests which make sure we will not
regress on this feature.