Eigsolve initialization

[lkdvos]

This PR adds some infrastructure to be able to hook into creating initial vectors for eigsolve.
This came up in #126.

I've added an overloadable eigsolve_init function that can be used instead.
Unfortunately, in order to make this backwards compatible this gets a bit messy with the multitude of different signatures that eigsolve needs to support.
For example, I'm not sure if it is that useful to support signatures with n to specify the size of the matrix. Replacing this with rand(T, n) would not really be that much more verbose, and would make dispatching a bit easier.

Considering the initialization of the sparse eigenvectors, I don't know enough about this topic to make an educated choice.
Is defaulting to dense vectors the correct way to characterize random eigenvectors? Should these be random sparse vectors with some specified sparsity instead?
Do we instead force users to provide a starting vector, or throw a warning?

[codecov]

Codecov Report

Attention: Patch coverage is 60.00000% with 4 lines in your changes missing coverage. Please review.

Project coverage is 85.88%. Comparing base (68ced46) to head (5ff8ce4).

Files with missing lines	Patch %	Lines
src/initialize.jl	40.00%	3 Missing ⚠️
ext/KrylovKitSparseArraysExt.jl	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #128      +/-   ##
==========================================
- Coverage   88.04%   85.88%   -2.17%     
==========================================
  Files          32       34       +2     
  Lines        3422     3379      -43     
==========================================
- Hits         3013     2902     -111     
- Misses        409      477      +68     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Jutho]

I agree that the different signatures with f, n and T are annoying and I would like to get rid of them in future versions. Ideally, I would just like it if users always provide a starting guess and this is the only allowed syntax, but maybe that is too harsh?

Of course, anything regarding initialisation that applies to eigsolve also applies to the other methods. So we could go with a syntax

function initialize(::typeof(eigsolve), ::TypeOfLinearMap, ...)
end

[lkdvos]

I think it is fair to always have to provide a starting guess, but I do expect that this will be a little harsh...
Perhaps a middle ground could be to remove the n and T arguments, so users can either specify x0, or implement initialize(::typeof(eigsolve), ::typeof(f)) for their objects/functions.

I think this is only necessary for eigsolve and svdsolve, since the linear solvers and exponentiators already have a vector to start from?

I can look into adding this is this sounds right, and see if I can deprecate the other syntaxes