fix: fix newline duplication on text share

[lionel-rowe]

Fixes https://github.com/RobinLinus/snapdrop/issues/408:

Each occurrence of \n\n is converted to \n\n\n when sending a message using the "right click/long press to send a message" feature.

This was due to an inconsistency between the contenteditable and innerText browser APIs, which causes empty lines to be rendered using the HTML <div><br></div>, which innerText reads as \n\n rather than \n; hence one\n\ntwo becomes <div>one</div><div><br></div><div>two</div>, which then becomes one\n\n\ntwo.

Fixed by replacing the <div contenteditable> with a normal <textarea>, which is backed by #textDouble, an invisible element with opacity: 0 and aria-hidden="true", in order to retain the automatic resizing of the parent element in line with the number of rows in the textarea.

Auto-resizing behavior demo after the fix (should look exactly the same as before):

Note that I added overflow: hidden; to the root html element for the purposes of the screen recording, to fix constantly disappearing and re-appearing root-level scrollbar (presumably related to https://github.com/RobinLinus/snapdrop/issues/196, but not relevant to this PR as it occurs both before and after the fix).

[fm-sys]

Using a div instead of textarea was explicitly requested to make the text fields auto-growing (see #202 #212). Please verify that #202 does get broken due to this PR...

[fm-sys]

Sorry, I've just read again through your PR description:

in order to retain the automatic resizing of the parent element in line with the number of rows in the textarea.

So it sounds like you had auto-growing in mind :)

[lionel-rowe]

Sorry, I've just read again through your PR description:

in order to retain the automatic resizing of the parent element in line with the number of rows in the textarea.

So it sounds like you had auto-growing in mind :)

Yes indeed! I've added a screen recording to OP to demo what the new behavior looks like (should be identical to the old).