Return just the solution in linalg.lstsq

[lezcano]

Description
linalg.lstsq is possibly one of the most algorithmically complex operations that the API supports. On top of that, it returns quite a bit of extra information besides the result: the residuals, the rank, and the singular_values.

The specification of the returns was discussed in this PR.

Problems

1. If the libraries wanted to expose a lower-level API that returns more information computed during the solution of the system they are free to do so, but a general API should be as simple and orthogonal as possible.
2. Lack of Orthogonality (Point 5 of the design principles): This function does the work of a number of other functions, namely linalg.svdvals and linalg.matrix_rank or simply just linalg.svd.
3. Lack of orthogonality 2. This function is a more general version of linalg.solve, which just returns the solutions. As such, their APIs should be comparable.
4. Usability. This function is, by far, the most complex operation in the whole API. We should provide an API for it that is easy to use by the non-expert.
5. The 4th return value assumes that we are solving the problem via SVD. This needn’t be the case and it goes against Point 4 of the design principles. This problem can be also solved via QR with pivoting. In fact, this is actually faster in many practical situations as long as the matrix A is well-conditioned.
6. The second return is there because some LAPACK algorithms return it. Some other LAPACK algorithms (e.g. gels) do not return these values in some cases, and they would need to be computed manually. In the best case, one would need to instantiate a large matrix of zeros, in the worst case, an extra matrix-matrix multiplication would be needed.

Proposal
Let linalg.lstsq return just the solution of the problem.

TODO
Have a look in scipy or other libraries and see how is this function used, whether users do actually use all the returned values or just the solution. It may very well be the case that users are just using the solution in most cases, similar to what happened with full_matrices=False in SVD

cc @asmeurer @rgommers @kgryte

[kgryte]

As discussed in gh-240, consensus was to remove linalg.lstsq from the specification altogether, thus obviating the need for a reduced API.