Leverage patmat for irrefutable filter elision

For-comprehension desugaring is spefified to elide the
`withFilter` call in `for (<pattern> <- xs)` if `pattern`
is irrefutable. But translating this corner of the spec
into a working compiler implementation has long been a
source of frustration and missteps.

The parser is able to detect irrefutability in trivial
cases, and elide the filtering. But for anything non-trivial,
(including, importantly, `for ((a, b) <- xs))`, it assumes
the filtering is required. The utility phase, `RefChecks`
attempts to find these calls, checks refutability (which
unlike it's myriad other tasks sort of matches its moniker!)
and elimiates the call if possible.

This is already problematic, because that possibly/maybe
call to `withFilter` can interfere with type checking
and inference. Tempting as it seemed, SI-6968 showed us
that we can't sidestep these by performing more pre-checks in
the parser.

The analysis in `RefChecks` has not been working at all
since the introduction of the new pattern matcher in Scala
2.10, as it is looking for a `Match` node that is now
translated earlier. Furthermore, it was making a common
mistake when on applications, forgetting to handle type
arguments.

So, history lesson over. Let's talk about the future.
Which is actually pretty simple.

We can exploit the fact that the pattern matcher runs
earlier by performing the refutability analysis
during match translation, and attaching the result to the
translated tree. `RefChecks` can now look for this attachment,
and eliminate the filtering.

This can only be done, however, `xs.filter(<irrefutable>)`
and `xs` have the same type. Sadly, this means the test
case for SI-4574 is not satisfied.

I've also cleaned up the legacy code path, but while
the enclosed test now at least calls `isIrrefutable`
under `-Xoldpatmat`, it doesn't come up with the
right answer. I don't think its worthwhile to investigate
that further.