Ensuring we always have a known boolean operator

[valencik]

This PR tackles a handful of issues:
(but hopefully the commits are still pretty isolated and clean 😬 )

• Support configuring default boolean (OR / AND)
  • this is accomplished by making QueryParser a class with a defaultBooleanOR param
• Changing Group to take only a single Query instead of a list
  • This addresses Problem 2 from Rethink Query hierarchy #142
  • the idea being that we should have a group of queries without knowing the boolean operator that connects them
  • Note: A MinimumMatch query is an exception to this, it contains a list of queries that truly are not linked by either an AND or OR
• Removes MultiQuery
  • This addresses Problem 3 from Rethink Query hierarchy #142
  • Also part of the effort to not have lists of queries with unknown boolean operators

There remain a handful of TODO comments in the tests.
This are mostly around needlessly nested queries. But I think resolving these might make this PR even larger...

[astronomerdamo]

I do find this defaultBooleanOR = false a bit awkward to work with implying that we have a parser with defaultBooleanAnd-like behaviour

[valencik]

I added a convenience method to the companion object so this now looks like:

val parser = QueryParser.withDefaultOperatorAND

Which is a bit more explicit.

[astronomerdamo]

Nice changes, thank you! Left an optional comment/question.

[astronomerdamo]

Perhaps worth noting that QueryParser.parse("cats OR dogs") also is OR by default?

[valencik]

maybe..... I don't know yet if we should keep the QueryParser.parse convenience forever...
So maybe, for now we encourage folks to be explicit with QueryParser.withDefaultOperatorOR.parse or QueryParser.default.parse and then eventually require it?

For now I think I prefer recommending the explicit thing.