Use LinearAlgebra.Diagonal instead of defining SDiagonal type

[simonbyrne]

Fixes #531. I've kept SDiagonal as a type alias for compatibility.

[mschauer]

Would be good to time this against scalem

[simonbyrne]

Hmm, it does seem to be about 10x slower for a 4x4 matrix. I wonder why it's so much slower?

[simonbyrne]

ah, I forgot to use $ interpolation. They're more or less the same.

[mschauer]

Thank you. I find it surprising that nothing is lost if a static array object is not inheriting into StaticArray or is there some trade-off I am missing?

[simonbyrne]

I'm not sure I understand what you mean. This is just using the broadcasting of static arrays

[c42f]

I think the point is that previously foo(m::StaticMatrix) would match SDiagonal, whereas it won't anymore. Now we get foo(m::Diagonal) to match instead.

I'm not sure which is best to be quite honest. One clear advantage of this PR is that we get to delete a bunch of code.

[simonbyrne]

Ah, I see. I personally think it makes sense to use Diagonal since
(a) that was the whole point of making Diagonal parametric
(b) we already do the same for factorization objects like Cholesky
(c) it requires less code to maintain

If you need a way to determine if the underlying structure is a StaticArray, perhaps that would be better done using traits?

There is probably still room to improve Diagonal in LinearAlgebra so that fewer method overrides are needed here.

[c42f]

Yes, I agree we can't have both, and that traits are a way out. I do think the changes here are probably a good idea, I'm just not using SDiagonal myself.

[c42f]

@mschauer it looks like you contributed SDiagonal originally. Would this change affect your packages much?

[andyferris]

Fundamentally, users should be able to wrap StaticArrays in their own array types without problems or caveats. I totally support that.

To my mind, we should see if we can support the "trait" of static-sizedness directly through length, size, axes and keys. We first need SUnitRange to work properly as it's own keys.

[c42f]

@andyferris you're right. I think we postponed this in the past (v0.5??) because the compiler couldn't deal with it. But the compiler has improved hugely since then.