Re-design highlighting logic to not affect caret position

[sbrudz]

Many of the outstanding bugs (#10, #12, #25, and #27) and the fixed bugs (#6, #8, #22) are related to how highlighting and cursor positioning are done. I've tried different fixes for the outstanding bugs but nothing has worked reliably and the code gets ugly quickly. When that happens consistently, it's a design smell and the design needs to be reconsidered.

The core issue is that when just-not-sorry highlights a word, it mutates the DOM. When words are edited (e.g., when "just for" gets changed to "justification for"), it needs to strip out the highlighting by deleting the DOM node. Deleting the node causes the cursor position to be lost. To address this, we programmatically set the cursor position back to what it was before, but this fails for certain edge cases (#10, #25) or has other side effects (#27). Finally, before the email is sent, it needs to strip out the highlighting, but for certain edge cases the stripping fails (#12).

The new design should do the highlighting without mutating the part of the DOM that contains the text you're editing.

An additional benefit of the redesign will be that we can more easily extend just-not-sorry to other web email clients (inbox, hotmail, etc. -- #4, #20) because we won't need to write and test new logic to strip out the highlighting for each email client.

The spike in commit c36981f shows that creating an overlay with the highlighting using Range.getBoundingClientRect is a viable solution.

This ticket is to track the work required to turn the spike into a production-ready implementation.