Make handling of tuples more consistent in quasi-quotes

On one hand we know that q"($expr)" is the same as q"$expr". On the
other if we wrap it into a list and splice as q"(..$expr)" we get a
Tuple1 constructor call which is inconsistent.

This pull request fixes this inconsistency by making q"(..$expr)" being
equivalent q"(${expr.head})" for single-element list.

We also add support for matching of expressions as single-element tuples
(similarly to blocks) and remove liftables and unliftables for Tuple1
(which aren't clearly defined any longer due to q"(foo)" == q"foo"
invariant).
SI-8270 unconfuses bundles and vanilla macros

This fixes a mistake in macro impl ref typechecking that used to have
an heuristic to figure out whether it looks at a bundle method ref or at
a vanilla object method ref. Under some circumstances the heuristic could
fail, and then the macro engine would reject perfectly good macro impls.

Now every macro impl ref is typechecked twice - once as a bundle method ref
and once as a vanilla object method ref. Results are then analyzed,
checked against ambiguities (which are now correctly reported instead
of incorrectly prioritizing towards bundles) and delivered to the macro
engine.

The only heuristic left in place is the one that's used to report errors.
If both bundle and vanilla typechecks fail, then if a bundle candidate
looks sufficiently similar to a bundle, a bundle typecheck error is reported
providing some common bundle definition hints.
Merge pull request #3521 from xeno-by/ticket/8270

SI-8270 unconfuses bundles and vanilla macros
Merge pull request #3499 from densh/topic/single-element-tuple

Make handling of tuples more consistent in quasi-quotes