Persist keywords in moz_keywords instead of using the Sync tables

[linabutler]

Before this patch, we stored keywords for incoming bookmarks in the
moz_bookmarks_synced table, and read them back out from that table
when we uploaded outgoing records. This was done for a few reasons:

• In the beginning, Rust Places didn't support search keywords at all.
  There are plans to unify keywords and custom search engines, since
  they solve the same problem, but it's not currently a priority.
  https://bugzilla.mozilla.org/show_bug.cgi?id=648398 has more
  context.
• However, keyword searches were a very popular feature in Firefox for
  iOS, so we added an API to read them out of moz_bookmarks_synced
  in Add and expose a getBookmarkURLForKeyword API. #1345.
• This was still fine, since the only way to get keywords into Fenix
  and iOS was via Sync. (Though there were some gotchas; for instance,
  disconnecting Sync would lose all keywords).
• But the Fennec to Fenix migration meant that there are now two ways
  to get keywords into Fenix, since Fennec supported setting them on
  bookmarks.

To make things more interesting, keywords are handled differently
across our products. Desktop exposes keywords as bookmark properties,
but, internally, associates them with (URL, POST data) tuples.
(This is also why they're closer to custom search engines than
bookmarks). But Sync, Fennec, and the old (before a-s) Firefox for iOS
associated them with individual bookmarks.

This patch takes a middle ground. Keywords are associated with URLs,
like Desktop, and we store those associations in a separate
moz_keywords table. This means keywords imported from Fennec should
be migrated, and signing out of Sync in Firefox for iOS no longer
loses keywords. Like Fennec and iOS, we don't support POST data,
since we don't sync it, and there's no UI for setting it.

The keyword syncing code is the same as Desktop's: we remove all
synced keywords from all local URLs, and all local keywords from old
and new synced URLs, then apply incoming items with new keywords and
URLs. We also flag items with the same keyword and different URLs,
as well as items with different keywords and the same URL, for
reupload, to enforce the "1 keyword per URL" association.

Pull Request checklist

• Quality: This PR builds and tests run cleanly
  • cargo test --all produces no test failures
  • cargo clippy --all --all-targets --all-features runs without emitting any warnings
  • cargo fmt does not produce any changes to the code
  • ./gradlew ktlint detekt runs without emitting any warnings
  • swiftformat --swiftversion 4 megazords components/*/ios && swiftlint runs without emitting any warnings or producing changes
  • Note: For changes that need extra cross-platform testing, consider adding [ci full] to the PR title.
• Tests: This PR includes thorough tests or an explanation of why it does not
• Changelog: This PR includes a changelog entry in CHANGES_UNRELEASED.md or an explanation of why it does not need one
  • Any breaking changes to Swift or Kotlin binding APIs are noted explicitly
• Dependencies: This PR follows our dependency management guidelines
  • Any new dependencies are accompanied by a summary of the due dilligence applied in selecting them.

[linabutler]

This needs more tests, but I thought I'd get the initial version up for feedback. Does all that make sense?

[mhammond]

This looks great. I agree it needs tests, and should it have a migration step to grab the keywords out of the _synced table? (Even if it should theoretically all come out in the wash, there seems a risk that the engine will end up reset before it syncs? But I guess that's the current status-quo...)

[linabutler]

I think this is ready for re-review! ✨ Also tagging @lougeniaC64, since she just reviewed tags and this is pretty similar. 😁

[lougeniaC64]

Admittedly it took me some research to understand what was happening (I haven't used keywords) but the explanation and the comments in the code were extremely helpful. This makes sense to me.

[mhammond]

🚀