LibVNCClient: support TightVNC's UTF-8 clipboard support

[felixonmars]

Describe the bug
When connecting to a TightVNC server, clipboard sync is still in latin-1 and ends up with question marks or garbage text.

To Reproduce
Connect to a TightVNC server, and try to copy unicode text from or to the remote device.

Expected Behavior
Unicode text remains the same across clipboards.

Logs/Backtraces
n/a

Your environment (please complete the following information):

• OS and version: Arch Linux x86_64, remmina or krdc with libvncserver 0.9.14
• Compiler and version: GCC 13.2.1

Additional context
TightVNC supports UTF-8 since version 2.8.53. Copied from its changelog:

Added support for Unicode clipboard transfers (UTF-8). The latest public version of the standard RFB protocol (3.8) does not support Unicode text, so we implemented this via a new TightVNC protocol extension. This feature will work when supported at both ends of the connection.

So probably an additional protocol extension is needed for this?

I have looked through its source code and found something that should be related:

[layercak3]

libvncserver and tigervnc implements the Extended Clipboard pseudo-encoding (from UltraVNC in 2010) which supports UTF-8. It looks like tightvnc has introduced yet another cut-text protocol. The Extended Clipboard pseudo-encoding does not introduce new client/server message numbers like in the screenshot, but instead modifies the behaviour of 3/6.

[bk138]

Hi @felixonmars, does #561 change/fix this for you?

[gujjwal00]

Related: TigerVNC/tigervnc#1662 (comment)

[bk138]

As pointed out by @layercak3, @gujjwal00 and @felixonmars themselves, TightVNC does Unicode cuttext via their own implementation. Thus turning this into a feature request someone might want to tackle.