Allow filtering based on the node name

[psss]

Add support for filtering based on the node name by allowing plain literals without the key: name format.

[psss]

Summary from the hacking session: Use no key for search by fmf node name. Example:

/tests/core & tag:quick

So we don't have to invent/decide any name ;-)

[lukaszachy]

/packit test

[lukaszachy]

@psss Is the "/tests/core & tag:quick" possible with current PR? It doesn't seem so. Also adding a unit test and similar example do the pydoc fmf.filter will be useful.

[The-Mule]

This actually brings some issues. See, right now fmf filter is unable parse regular expressions that are quite common and that I assume people will likely be using (there is already a misplaced issue in tmt project for this. This problem is solvable[*] under the assumption that keys are always used. But once this PR is merged this assumption is gone.

[*] Using a positive lookahead assertion as follows:

# At least one clause must be true
    return any([check_clause(clause)
                for clause in re.split(r"\s*\|\s*(?=[^|]*:)", filter)])

Once you have | in a regexp the only way to distinguish it from proper disjunction is to to check that some key follows it. If not then it must be a part of value of the last key. Same approach can be applied to identifying a proper conjunction. With that you can already use pretty powerful regular expressions as values (you still need to avoid using both | and : in you regexp, but probability of that is fairly low IMO). Allowing not to have a key will break this logic.

[lukaszachy]

Once you have | in a regexp the only way to distinguish it from proper disjunction is to to check that some key follows it. If not then it must be a part of value of the last key. Same approach can be applied to identifying a proper conjunction. With that you can already use pretty powerful regular expressions as values (you still need to avoid using both | and : in you regexp, but probability of that is fairly low IMO). Allowing not to have a key will break this logic.

With escaping it is clear whether | is part of filter syntax or regexp (\|). Escaping of ':' is already supported (driven by colon used in module nsv strings used as component value), escaping '&' and '|' are planned in this release.

[psss]

@psss Is the "/tests/core & tag:quick" possible with current PR? It doesn't seem so. Also adding a unit test and similar example do the pydoc fmf.filter will be useful.

Implemented and documented. @lukaszachy, please review.