Improve scalartype determination at start of algorithms

[lkdvos]

Here I tried to slightly more carefully treat determining the scalartype that will be used in the algorithms.
Importantly, I attempted to reinstate the type inference as a first attempt, since it would be nice to avoid having to do a function evaluation and allocations etc when this is not necessary.
Nevertheless, this still retains fallback solutions for when type inference fails, and should also still error at a reasonable place when the function fails itself.
I also added this behavior to the generalized eigenvalue solvers.

This should also fully fix #132, which technically already was more or less fixed before.
We might have to add some additional tests for this though, but I'm not sure what the best way is to construct things that are type unstable in a reliable way.

[codecov]

Codecov Report

❌ Patch coverage is 84.00000% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.44%. Comparing base (7deee27) to head (112c594).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
src/apply.jl	80.00%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #138      +/-   ##
==========================================
- Coverage   88.54%   88.44%   -0.10%     
==========================================
  Files          36       36              
  Lines        3938     3948      +10     
==========================================
+ Hits         3487     3492       +5     
- Misses        451      456       +5     

☔ 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.