New highlight serialization format

[jeromepl]

For v5 I would like to add a new way of serializing highlights that is more robust to dynamic webpages or changes to static pages.
Instead of using an anchor and focus elements that are serialized by CSS query selector, I think a smarter scheme could be designed by finding a parent element that has "sufficient" chance of being unique. This parent could be identified by content (hash), rather than by query selector. within this parent then, we can have the query selector for the focus and anchor.

Note that this is not resistant to changes in the rest of the content within this parent selector, which might make it worse in some cases. Anyway, I believe there is a lot of room for improvement for robustness of storing and restoring highlights

[jeromepl]

Using the same format of the scroll-to-fragment proposal could make sense here. This is what is used in Chrome to highlight search engine content and provide a context option "Copy link to highlight". Possible implementations that could be used:

• https://code.treora.com/gerben/text-fragments-ts
• https://github.com/GoogleChromeLabs/text-fragments-polyfill

Note that something else that could be nice to leveraged is that we can detect when there is such a fragment and propose to the user to save this highlight. Note: to detect this, looking at window.location does not work, and the fragments info is not yet exposed to the page (see issue 128 from the repo linked above). However, we CAN get this information from the background page on the chrome.tabs.onUpdated event on the changeInfo.url property.

Reversely, we can also create a link to share a highlight using this so that people receiving the link don't need to have the extension installed for the highlight to work (although for now this is only supported in Chrome).