Support arbitrary searches

This may or may not be possible. I've dreamed up this thing while sleeping, literally.

Currently, the search bar allows an item code as an input. And it redirects to the Item view page. it's not even a real search.

However, the data we have is very structured, so we could allow some simple and structured (not really arbitrary) searches, which are still faster than selecting things from a multi-level dropdown menu like they are now...

Some strings that may be supported:

• ddr2 dimm ram in labfis4
• black case with usb ports > 2
• working graphics card with pci express in chernobyl
• item with code c__ in chernobyl
• working ddr2 dimm ram inside broken case in chernobyl
• case with cib = 112233
• ddr2 dimm ram order by brand asc

A possible solution to parse these search strings would be to scan the input for an item type (or a generic item for any type) and then try to understand what's around it, according to a pattern:

• on the left we have "adjectives" which are just ValueEnum values
• on the right we have "in + something" for a location filter
• on the right we could also have or "with + something" for Value
• with code as a special case
• If a comparison is provided after a Value, e.g. > 2, then use that; otherwise assume it's > 0: if it has to have PCI Express, it has to have at least 1 PCI Express socket or connector, right?
• If we want to get real fancy, we could add support for with more than 2 usb ports and with at least 2 usb ports and similar
• An = means = obviously. If we want to get even fancier these could be possible: case with cib of 112233, case with cib like 1122%, case with cib similar to 1122%, etc...
• inside maps to the "ancestor" search filers. inside is followed by [adjectives] type [with + something] which will be part of the "ancestor" filter, anything else (another in in the example) is part of the main search
• order by is like an SQL ORDER BY, it has to be placed at the end

This will be a big issue that requires a lot of thinking and experiments, but it should be mostly possible without modifying data or the search query: we just need to parse that string as an input, ad provide a Search object as an output, all the examples map cleanly to that!

Suggested steps:

• Figure out what if these examples could cover the majority or at least a big chunk of the cases, without being too confusing or limiting
• Read all ValueEnum and Feature values, alias the ones that need aliasing (i.e. "broken" instead of "no", because it is "working = no" but there are other features that have "no" as a possible ValueEnum, also replace dashes with spaces, remove the -n and other units from feature names, try to use human-readable names somehow, etc...)
• Attend the "Formal languages and compilers" course
• Write a formal grammar for this language (it's pretty easy since there's very little recursion and nothing to compute, don't worry)
• Generate a parser for the grammar
• Build the Search object from parser results
• Put all the pieces together (write the Controller method, etc...)

P.s. our lab is nicknamed "Chernobyl", that's why it's in the examples