Add checks for matching shapes in Solve, SolveH, and EighInplace

[jturner314]

Whenever two arrays are used in a single operation, we need to check that the shapes are compatible. Without these checks, we get segfaults, etc.

[codecov]

Codecov Report

Merging #290 (d7e5672) into master (6de9acc) will increase coverage by 0.08%.
The diff coverage is 94.54%.

@@            Coverage Diff             @@
##           master     #290      +/-   ##
==========================================
+ Coverage   89.01%   89.09%   +0.08%     
==========================================
  Files          71       71              
  Lines        3578     3633      +55     
==========================================
+ Hits         3185     3237      +52     
- Misses        393      396       +3     

Impacted Files	Coverage Δ
ndarray-linalg/src/solve.rs	72.18% <66.66%> (-0.41%)	⬇️
ndarray-linalg/src/eigh.rs	92.30% <100.00%> (+0.47%)	⬆️
ndarray-linalg/src/solveh.rs	74.50% <100.00%> (+0.77%)	⬆️
ndarray-linalg/tests/eigh.rs	100.00% <100.00%> (ø)
ndarray-linalg/tests/solve.rs	100.00% <100.00%> (ø)
ndarray-linalg/tests/solveh.rs	100.00% <100.00%> (ø)

---

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 6de9acc...d7e5672. Read the comment docs.

[jturner314]

The primary question is whether to panic or return an error in the case of mismatching shapes. @bluss or @termoshtt do you have an opinion on this?

[bluss]

(I'm not a maintainer of this crate) I don't know the error handling story in this crate so well, but panic on shape mismatch fits my general definition quite well. It's not a very "dynamic" condition: the program should be constructed so that it's known the two inputs have compatible shapes at that point in the program, otherwise there was a bug.

[termoshtt]

but panic on shape mismatch fits my general definition quite well. It's not a very "dynamic" condition

This should be correct.