Bad error message when having a single handler that's supposed to match everything

[WebFreak001]

Example:

	int someFun(T)(T v)
	{
		static assert(!is(T == int));
		return 3;
	}

	SumType!(int, string, This[]) v;
	v.match!(all => someFun(all));

use-case is that I have a generic (de)serialization function that's supposed to work on every type of my sumtype, but it doesn't for one. The current error message says something like:

/usr/include/dlang/dmd/std/sumtype.d(1998,13): Error: static assert:  "`handlers[0]` of type `template` never matches"
/usr/include/dlang/dmd/std/sumtype.d(1590,52):        instantiated from here: `matchImpl!(SumType!(typeof(null), string, bool, long, double, This[], This[string]))`
source/workspaced/backend.d(132,15):        instantiated from here: `match!(SumType!(typeof(null), string, bool, long, double, This[], This[string]))`
source/workspaced/backend.d(149,22):        instantiated from here: `deepCopy!(SumType!(typeof(null), string, bool, long, double, This[], This[string]))`
source/workspaced/backend.d(136,40):        instantiated from here: `deepCopy!(SumType!(typeof(null), string, bool, long, double, This[], This[string])[string])`
source/workspaced/backend.d(113,30):        instantiated from here: `deepCopy!(Section)`

which is hard to debug.

I propose to add a special case for single-pattern match invocations, where it will just shove it into my custom handler without testing if it's plausible and just let compiler errors break it.

[pbackus]

As discussed in #82, solving this properly will require improving __traits(compiles) so that matchImpl can get access to the error messages produced when a handler fails to match.