For cangjie* and quick* tables: Use big5 order if the freq from the table is the same

In the cangjie5.txt table, all the frequency weights are 1000, for example:

    su	己	1000
    su	已	1000
    su		1000
    su	㔾	1000

Currently, the Unicode code point is used as a last ditch fallback if
all the other sort keys are the same (sort keys are: exact match, user
frequency, Chinese variant, system frequency, length of input
sequence, input sequence alphabetical, Unicode code point).

In case of the above characters matching “su”, the Unicode code
points and Big5 code points:

    㔾 U+353E Big5 -    Big5HKSCS 8BC8
    己 U+5DF1 Big5 A476 Big5HKSCS A476
    已 U+5DF2 Big5 A477 Big5HKSCS A477
     U+E81D Big5 -    Big5HKSCS -

Sorting via the Unicode code points gives:

    尸山 (1/9)
    1. 㔾
    2. 己
    3. 已
    4. 
    ...

And sorting first via the Big5 code points and then via the Unicode
code points for characters which do not have a Big5 code point gives:

    尸山 (1/9)
    1. 己
    2. 已
    3. 㔾
    4. 
    ...

This order seems to make more sense for Cangjie because:

• https://en.wikipedia.org/wiki/Big5:
  “The original Big5 character set is sorted first by usage frequency,
  second by stroke count, lastly by Kangxi radical.”
• some other popular operating system also uses Big5 order for Cangjie

Therefore, for the cangjie* and quick* tables, this commit introduces
another sort key sorting according to the Big5 code point just before
sorting the final sort key using the Unicode code point.

As the frequency data in the tables (which is currently always 1000
for cangjie5.txt, cangjie3.txt, and cangjie-big.txt) has higher priority,
one could still tweak the frequency data in the table if the order is
still not perfect for some characters. But it looks like Big5 order
is quite reasonable.