Remove constraint on AbstractPDMat

[oxinabox]

Closes #1219
Tests it works by using BlockDiagonals.jl

Basic philosophy:

• Anything that worked with PDMats before should be just as fast
• Anything that didn't work before should be correct, but might be slower
  • (e.g. we might recompute the cholesky everytime rand is called)

TODO

• logpdf
• rand
• sqmahal(d::MvNormal, x::AbstractVector)
• sqmahal(d::MvNormal, x::AbstractMatrix)
• MvNormalCanon
• Implement fallbacks for (un)whiten(!) and (inv)quad(!) to AbstractArray PDMats.jl#162 needs to be merged and tagged

[devmotion]

I think it would be great if it would be possible to use different matrices and types as covariance matrices.

I'm not happy about the added complexity in Distributions though and think there should be a better way to handle this. In particular, I think that similar generalizations are also desirable in other scenarios where currently AbstractPDMats are required.

Maybe we could instead add these fallbacks of invquad, invquad!, unwhiten! etc. for AbstractMatrix to PDMats instead? And then only loosen the restrictions in the types of e.g. MvNormal in Distributions?

[oxinabox]

I think that would make sense.
It also would make it easier for other matrix packages to overload them.

One issue is I have no interest in implementing all of them, just like these 3, which is all we need for MvNormal.

@andreasnoack what do you think. Would such a PR be welcomed to PDMats.jl?

I would still want to add these test types here.

---

One thing I have shown here right now is the code changes are not hard or deep.
Just a few operations.
This is much easier than creating the work arounds.

[oxinabox]

This should now be good to go.

[devmotion]

I started the registration process for PDMats 0.11.11: JuliaRegistries/General#61420 Let's rerun tests when it's available.

[devmotion]

I guess here we might want to change it to

Suggested change

	function MvNormal(μ::AbstractVector{<:Real}, Σ::AbstractPDMat{<:Real})
	function MvNormal(μ::AbstractVector{<:Real}, Σ::AbstractMatrix{<:Real})

[oxinabox]

The tests pass, right now.
It took some effort to make sure the constructors cover the right cases and don't stackoverflow, or ambiguity error.
I could go and give them another pass over now that it is working, but I wouldn't want to just go and relax the ones there right now whily-nilly

[devmotion]

I think without this relaxation you can provoke a test error when you use something like MvNormal(::Vector{Float32}, ::BlockDiagonal{Float64}).

[devmotion]

This change is not needed it seems, is it?

Suggested change

	μc = convert(AbstractArray{R}, μ)
	Σc = convert(AbstractArray{R}, Σ)
	MvNormal{R, typeof(Σc), typeof(μc)}(μc, Σc)
	MvNormal(convert(AbstractArray{R}, μ), convert(AbstractArray{R}, Σ))

[oxinabox]

It is so we can call the parameterized constructor.
Otherwise we get a stackoverflow.

[devmotion]

Suggested change

	function MvNormalCanon(μ::AbstractVector{T}, h::AbstractVector{T}, J::P) where {T<:Real, P}
	function MvNormalCanon(μ::AbstractVector{T}, h::AbstractVector{T}, J::AbstractMatrix{T}) where {T<:Real}

[devmotion]

I guess we want to keep this function but change J::AbstractPDMat to J::AbstractMatrix{<:Real}.

[devmotion]

For the old function here (relaxed to AbstractMatrix, see above):

Suggested change

	MvNormalCanon{T,P,typeof(μ)}(convert(AbstractArray{R}, μ), convert(AbstractArray{R}, h), convert(AbstractArray{R}, J))
	MvNormalCanon(convert(AbstractArray{R}, μ), convert(AbstractArray{R}, h), convert(AbstractArray{R}, J))