Make usage of engine name and dconf key consistent

The setup tool did write to a different dconf key than the
engine.

Make this consistent. If the file name of the table is

    /usr/share/ibus-table/tables/wubi-jidian86.db

use

   table:wubi-jidian

as the ibus engine name (listed by “ibus list-engine” and used
in the environment variable IBUS_ENGINE_NAME).

As the dconf key, use:

    /desktop/ibus/engine/table/wubi-jidian86

The name found in the source of the table (i.e. in wubi-jidian86.txt
in the source package of ibus-table-chinese), which looks like

    ### The default name of this table
    NAME = WuBi-Jidian (JiShuag) 86

should not be used for the dconf key or the engine name, it should
only be used for display in the user interface.
Don’t switch off pinyin mode in clear()

clear() is called in do_focus_out().  And do_focus_out() is called
after clicking into the gnome menu to switch to pinyin mode.  This
makes it almost impossible to enable pinyin mode and keep it when
pinyin mode is switched off in clear().
Don’t use “try:” to call self._editor.clear() in do_focus_out()

Why should self._editor.clear() ever fail? If problems can
occur there, they should be handled properly there.
Don’t try to colour system phrases and user phrases differently in pinyin mode

In pinyin mode, there are no user defined phrases.  Therefore, the
array holding a candidate does not have two integers at the end, only
one. candi[-2] is already the phrase, i.e. the chinese character in
pinyin mode, not an integer specifying a frequency.

Resolves: rhbz#1084684 - [abrt] ibus-table: table.py:670:ap_candidate:TypeError: unorderable types: str() < int()
See: https://bugzilla.redhat.com/show_bug.cgi?id=1084684
If keychar is empty, do not treat it as valid input

This makes typing the right shift key toggle between pinyin mode and
table mode, as intended.

In Python

    >>> '' in 'abc'
    True

Therefore, “keychar in self._valid_input_char” is True even if
keychar is empty. But if keychar is empty, one should not treat it
as valid input.

This problem occured when pressing Shift-Right, it was treated
as valid input and the following traceback was seen:

Traceback (most recent call last):
  File "/local/mfabian/src/ibus-table/engine/table.py", line 1596, in do_process_key_event
    result = self._process_key_event (key)
  File "/local/mfabian/src/ibus-table/engine/table.py", line 1618, in _process_key_event
    return self._table_mode_process_key_event (key)
  File "/local/mfabian/src/ibus-table/engine/table.py", line 1856, in _table_mode_process_key_event
    res = self._editor.add_input ( keychar )
  File "/local/mfabian/src/ibus-table/engine/table.py", line 398, in add_input
    res = self.update_candidates ()
  File "/local/mfabian/src/ibus-table/engine/table.py", line 804, in update_candidates
    self.pop_input ()
  File "/local/mfabian/src/ibus-table/engine/table.py", line 409, in pop_input
    self._tabkey_list.pop()
IndexError: pop from empty list
Fix goucima parsing from the source, broken by Python3 port

This regular expression:

    patt_s = re.compile(r' *([^\s]+) *\t *([\x00-\xff]{3}) *\t *[^\s]+ *$')

which tries to match single Chinese characters as a sequence of 3
bytes does not match anymore after the Python3 port because Python
strings are always unicode now and each Chinese character is thus a
single character in a string.
Merge pull request #32 from mike-fabian/fix-pinyin-mode-and-dconf-usage

Fix pinyin mode and dconf usage