Add LinearAlgebra: lu, lq, svd, qr

[oxinabox]

This will close #12
or at least get closer to it.

Right now I just have lu! (which gives lu and det and logdet).
I thought it might be good the share now to get feedback on the design of how to represent the factorization types.
This needs tests.

[oxinabox]

The same trick can be done for SVD, but it is a bit gross,
as it will attach the same labels to U as to Vt,
which will be wrong for both of them
but then during getproperty we can correct them by inserting the wildcards as required.

[codecov]

Codecov Report

Merging #24 (d54b9cd) into master (77eafa0) will decrease coverage by 0.05%.
The diff coverage is 94.33%.

@@            Coverage Diff             @@
##           master      #24      +/-   ##
==========================================
- Coverage   94.79%   94.74%   -0.06%     
==========================================
  Files          11       12       +1     
  Lines         423      476      +53     
==========================================
+ Hits          401      451      +50     
- Misses         22       25       +3     

Impacted Files	Coverage Δ
src/NamedDims.jl	100.00% <ø> (ø)
src/functions_linearalgebra.jl	94.33% <94.33%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 77eafa0...d6180f7. Read the comment docs.

[oxinabox]

The fact that we often store the dimension names via settign the type of factors or some arbitary field of the factorization is kinda hacky.
It will cause things to break hilariously if anyone uses getfield to access the fields of the Factorization.

I think it is fine, because LinearAlgegra basically accesses the underlying fields still via getproperty
and we always either strip the names or return the correct names from getproperty.
Infact we might even be able to do better by adding names to things that don't normally have them in getproperty to make more underling math work out.
even more danger-zone there though.

Alternative might be to have a NamedFactorization type, or something like that

[nickrobinson251]

Starting to agree this is a kinda cool idea 😄

[nickrobinson251]

sneaky! 😹

[oxinabox]

I should rebase this, and address the comments on the PR.
If i had time...

[rofinn]

@oxinabox If you wanna rebase your branch I can work on addressing the comments. I think making a NamedFactorization type makes sense to me.

[oxinabox]

I will rebase this tomorrow then and you can take it over.

[oxinabox]

@rofinn done. That was a weirdly hard rebase

[rofinn]

Alright, now that my changes have been merged back I'm happy to approve, but maybe @nickrobinson251 wants to give it one more look over?

[rofinn]

Should we just merge this as is and then I can update AxisKeys.jl?

[oxinabox]

yes?
I thought you had taken over this PR.
Oh were you waiting for @nickrobinson251 ?

[rofinn]

Yeah, cause Nick was the original reviewer for this PR.

[nickrobinson251]

Oh sorry I wasn't aware this was waiting on me. I'll take a look tomorrow :)

[nickrobinson251]

LGTM.

One question about tests for iterate (but i might just have missed them)