fix handling of implicit and before parens

Fix an oddity in matching options and preferred content expressions such as
"foo (bar or baz)", which was incorrectly handled as if it were "(foo or
bar) and baz)" rather than the intended "foo and (bar or baz)"

Seemed like a change to consume should be able to handle this case
better, but I was having trouble writing it that way, so instead added
a separate pass that inserts the implicit ands explicitly. Also added
several test cases to make sure versions with and without explicit ands
generate the same.

doc/bugs/parens_without_explicit_and__47__or_gives_wrong_matches.mdwn

@@ -82,3 +82,5 @@ b.2
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 
 Yes! [My description from before](https://git-annex.branchable.com/bugs/async_external_special_remote__39__s_stdin_not_closed/) still applies. And I've continued growing my annex and expanded onto a new drive since then.
+
+> [[fixed|done]] --[[Joey]] 

doc/bugs/parens_without_explicit_and__47__or_gives_wrong_matches/comment_1_8160d9308dc19b3c6a0596f437134e28._comment

@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-01-28T16:54:29Z"
+ content="""
+Let's see, here's the equivilant after parsing:
+
+	# ghci Utility/Matcher.hs
+	-- foo and (bar or baz)
+	ghci> generate [Operation "foo", And, Open, Operation "bar", Or, Operation "baz", Close]
+	MAnd (MOp "foo") (MOr (MOp "bar") (MOp "baz"))
+	-- foo (bar or baz)
+	ghci> generate [Operation "foo", Open, Operation "bar", Or, Operation "baz", Close]
+	MOr (MAnd (MOp "foo") (MOp "bar")) (MOp "baz")
+
+So it's interpreting "foo (bar or baz) like "(foo and bar) or baz"
+which is surely a bug.
+
+Fixed.
+"""]]