Properly encode pasted text containing newlines

[akinomyoga]

This fixes #1959.

I received a report in my project (akinomyoga/ble.sh#544).

The problem is that Tilix currently sends the raw text to the terminal application with its advanced paste dialog. However, the data sent to the terminal application is not plain text but should properly be encoded following the convention of the terminal communication. In particular, the newlines should be encoded by \x0D (which has an equivalent byte representation as CR \r in an ASCII string) in the traditional terminal protocol because \x0A (which has the same byte representation as LF \n in an ASCII string) means C-j in the convention. Actually, \x0D is technically C-m, but it is traditionally used as a synonym of RET. If one wants to send the multiline text preserving the variations of newlines, when the terminal application requests the bracketed paste mode, the terminal should use the bracketed-paste-mode beginning/ending markers of the pasted text. All this processing is supposed to be handled by VTE's vte_terminal_paste_text, but Tilix currently uses vte_terminal_feed_child to directly send the raw pasted text.

The same problem has been reported in #1959 for nano.

Ideally, we should use vte_terminal_paste_text through GtkD's Terminal::pasteText. However, this interface of GtkD has not yet been released. In this PR, we instead convert the newlines manually. I have confirmed that both issues #1959 and akinomyoga/ble.sh#544 are fixed with this change.

[akinomyoga]

I requested a new release of GtkD (gtk-d) for vte.Terminal.pasteText in the upstream GtkD project, and they tagged a new release 3.11.0. I think it will be available on the DUB repository soon.

[akinomyoga]

Since the latest version of GtkD (gtk-d:3.11.0) became available on the DUB repository, I updated the library version in commit 9635921. Then, in commit 70781c8, I switched to using vte.Terminal.pasteText to send the pasted text, which is a dedicated method that VTE provides for pasting text.