Fix method ambiguity for qr (#931) and lingering ambiguities for lu

[thchr]

This basically does just what #921 did to fix #920 for #931; i.e., removes the ambiguity for qr.

While doing that, I noticed that #921 hadn't completely resolved the ambiguity for lu; e.g., if called as lu(A, Val(false)) there would still be an ambiguity error; so I fixed that as well. Similarly, I believe it would previously have been ambiguous if provided with a check keyword argument.

Added a few tests as well.

[thchr]

The failure on nightly is unfortunately related to the strategy for resolving these ambiguities: det doesn't infer because it calls lu(::StaticMatrix, Val{...}; check) which now no longer infers because it @invokes a method with a keyword argument. I.e., this happens:

f(x::Float64; kw=2) = x+kw
f(x::Int;     kw=2) = x+kw

fInt(x; kw=2) = Base.@invoke f(x::Int; kw)
fFloat(x; kw=2) = Base.@invoke f(x::Float64; kw)

where neither fInt nor fFloat infers, despite both methods of f inferring just fine.

So the crux of the problem seems to be that using @invoke to define lu with a check kwarg is bad: but the check kwarg is needed occasionally (e.g. in det apparently).

What would be a good way to sidestep this? Not inferring on lu obviously isn't workable.

[thchr]

The issue with @invoke and keyword arguments was already noted previously in JuliaLang/julia#29216.

[thchr]

Okay, to fix this, I just dropped the @invoke approach entirely and used @eval to instead define methods only for Val{true} and Val{false} pivots, avoiding the need to define the ambiguous Union{Val{true}, Val{false} method at all.
I did this for both qr and lu for consistency, although it's only really necessary for lu.

Locally, all tests pass for me on nightly now.

[mateuszbaran]

Thanks for investigating it, this approach looks fine. Could you bump the patch version?

[thchr]

Sure: done!