[FEATURE] Add the ability to delete/ignore a word

[saxoncameron]

Discord user ガリン#4920 reports repeated issues with incorrect readings, a.k.a. parser imperfections. e.g.

My reply, for context:

I don't think we can fix this. As @bent says, we can look at the output that Mecab (the parser under the hood) uses, but if that's what Mecab gives us, that's what you get I'm afraid. Like the parser in the browser extension, it's never going to be 100% perfect
then can you add the option to hide/ignore wrong words

An on-hover icon UI for vocab words would be a great compromise for the expected imperfections of the parser. And would eventually complement the "star" system we have planned as a future feature (#114). I think this is higher priority than a starring system, though.

Implementation considerations

• How/where do we store the data, regarding which words have been deleted/ignored?
• What do we "do" with deleted/ignored words? Perhaps it might be best to move them to the end of the vocab word queue, in a collapsed section, so that they can be viewed/restored. Lest we have to figure out how to reset that kind of data.

[saxoncameron]

I envision this as an on-hover icon UI, perhaps as one of three actions, including:

• editing ([FEATURE] Ability to "edit" a vocab word's reading #160)
• starring, to "pin" an example word to the card front ([FEATURE] Starring system for linked vocab, stories #114)
• deleting/ignoring ([FEATURE] Add the ability to delete/ignore a word #158)

[RicBent]

Assuming all these features would be tied to specific kanji (and not across multiple) the background implementation for this would be pretty simple:

I'd just expose lists like these to the JS context:

words_ignored: [[word1_kanji, word1_reading], [word2_kanji, word2_reading], ...]]
words_starred: [[word1_kanji, word1_reading], [word2_kanji, word2_reading], ...]],
words_edited: [[word1_kanji, word1_reading, word1_reading_edited], [word2_kanji, word2_reading, word2_reading_edited], ...]],

Additionally, I'd expose bridge commands that take the modified lists and save them back to the db.

I'm all for implementing these features, however, I don't think we should touch further features on the JS side before doing #65.