rustc: Don't call type_error_message() with ty_err as the expected type

[catamorphism]

r? @nikomatsakis In #6319, several people mentioned they ran into a "computing
fictitious type" ICE in trans. This turns out to be because some
of my recent changes to typeck::check::_match resulted in type errors
getting reported with ty_err as the expected type, which meant the errors
were suppressed, and typechecking incorrectly succeeded (since the errors
weren't recorded).

Changed the error messages in these cases not to use an expected type at all,
rather, printing out a string describing the type that was expected (which is
what the code originally did). The result is a bit repetitive and the
proliferation of error-reporting functions in typeck::infer is a bit annoying,
but I thought it was important to fix this now; more cleanup can happen later.

[nikomatsakis]

I confess I don't really understand the effect of this change, but as you say I think we ought to fix it first, ask questions later. Clearly I have to read into this business of suppressing errors based on the expected type a bit more.

[catamorphism]

@nikomatsakis The basic issue isn't that complicated, I just didn't explain it well. The error-reporting functions currently accept an expected type and an actual type, and suppress the error if either is ty_err. But the pattern-match-checking code is top-down, so there's no expected type to use. So in my last commit to this code, I synthesized an expected type based on the structure of the pattern and the actual types of the sub-patterns. This usually didn't work because the pattern-match-checking code would check the sub-patterns with ty_err as an expected type once an error was detected -- so then, reporting an error for the parent pattern, the expected type would be ty_err and no error would be reported. But, ty_err would get written into the type context, causing the trans error that we saw later.

Hopefully that's clearer...