Dynamically-indexed settings search

[conker-rsc]

This was inspired by PR #150. I very much liked the UX design in that pull request, but wanted a more robust implementation.

Features:

• Dynamic indexing
  • Programmatically discovers all fields without having to manually tag them for search
  • Groups components that are children of the same panel, as they would belong to a single "setting"
  • Makes it simple to add new config items without having to worry about searchability
  • Tracks component visibility before and after re/indexing so things will never become visible that shouldn't
  • Supports several options to override default indexing behaviors on a per-component basis, such as panel grouping
• Reindexes as-needed to account for user input and GUI changes
• Indexes all user inputs, allowing users to search on their own values
• Indexing strips inline html/css
• Robust search parsing
  • Example: searching for "ground items" will match the option for "display the names of items on the ground"
• "Go To" button / ENTER key takes you to the first visible matching component
• "Clear" button / ESC key resets the search
• Contextual tab awareness
• Proper scroll bar management during search
• Ability to add search metadata to cover synonyms etc. Examples include:
  • Adding "roofs" and "rooves" to the "roof hiding" option
  • Adding "color" in places using the British spelling of "colour"
  • "sleeping" and "bag" to the "sleep" keybind
  • "sfx" to match on "sound effects"
• Ability to mark components as unsearchable, such as section headers
• Ability to arbitrarily group components for searching
• Ability to exclude a component's text from being searchable
• And more

A good place to start on this review for understanding how the code works is the javadoc for the indexSearch() method

[Hubcapp]

Love it, thanks for your very hard work on this. Love the implementation with getAllComponents.

I suspect we will want to go back and add search aliases to some more of the existing options e.g. "hits" "hp" and "health" are all pretty interchangeable & are used often.

[Hubcapp]

Maybe only two things eyebrow raising:

• 900 kb of additional libraries to remove HTML. Maybe a regex to just delete anything between angle brackets would have been fine?
• Sometimes the top option in a section has padding applied to the top in order to separate it from the header. When the top option is filtered, then the padding on that "top element" does not appear, and the result is squished next to the header. I'm not sure if it is possible to add these paddings to the bottom of the header instead. Can come back to this after flatlaf.

[conker-rsc]

Definitely on the aliases; I’ll add the hits stuff now but please feel free to make any other suggestions you can think of that I can get in before the initial feature merge!

Yes I started with plain regex and then figured out it wasn’t enough for some reason that I can’t remember now… I’ll take a fresh look at it again, it was one of the earlier things I did.

Noticed the header padding too (was literally one of my TODOs) but couldn’t remember if that’s something I already fixed in my FlatLAF branch and then came to the same conclusion you did, that I would deal with it there haha.

[conker-rsc]

Regarding the HTML; it was for un-escaping HTML values such as  ... I wanted to ensure that in the future anyone could use whatever values they would like, without us having to maintain a list, or re-invent the wheel and re-implement what libraries already do.

That said, I did a little bit more research and found that the JSoup library is capable of doing the exact same thing that I'm using it for here at about half the size (443.3kb). I tested it out and the outcome is the same as the apache library.

I'll leave it up to you whether you're okay keeping the JSoup library, or if you want me to re-implement its logic within RSC+.

EDIT: Seems like by using the JSoup library, I can get rid of the custom regex within the sanitize method, which leads to MUCH better and cleaner results from parsing as well. As such, my vote is to keep the JSoup import in place.