[yencode] Fix an unlikely bug that may trigger packet loss pattern detection in D-Star

[dscp46]

Hi team,

Per D-Star specification, section 6.2, our output shall be escaped so that the pattern 0xE7, 0x84, 0x76 never appears in a DV Slow data packet. This is because it might trigger the packet loss logic if combined with the silence pattern in the voice section:

データフレームが 0xE7, 0x84, 0x76 のデータ列となり、かつ音声フレームが無音 パターン 0x9E, 0x8D, 0x32, 0x88, 0x26, 0x1A, 0x3F, 0x61, 0xE8 の場合にパケッ トロスとして扱うため使用できません。

This PR is a change proposal to patch that unlikely bug.

Unlike what is recommended in section 6.2, the easiest way to ensure we don't trigger aforementioned the packet loss mechanisms would be to either add 0x76 or 0x84 to the list of banned characters (0xE7 is a reserved DV Slow data miniheader value, escaping it may still make the bug viable in the future).

If you are willing to stick to the standard by the letter, at the price of a higher overhead, please free to edit that PR to add 0xE7 and 0x76 to the banned list (on a side note, none of the 3 characters become a banned character once escaped).

Unpatched implementations are forward compatible with this change, since yDecoding doesn't rely on the banned character list to unescape characters.

Best regards,

[wb8tyw]

Adding this to #302 to get a common commit message structure.