Integer matrix exponentiation in schurpow

[jishnub]

This improves type-inference by avoiding recursion, as the A^p method calls schurpow if p is a float. After this, the result of schurpow is inferred as a small Union:

julia> @inferred Union{Matrix{ComplexF64}, Matrix{Float64}} LinearAlgebra.schurpow([1.0 2; 3 4], 2.0)
2×2 Matrix{Float64}:
  7.0  10.0
 15.0  22.0

One concern here might be that for large p, the A^Int(p) computation might be expensive by repeated multiplication, as opposed to diagonalization. However, this may only be the case for really large p, which may not be commonly encountered.

I've added a test, but I'm unsure if schurpow is deemed to be an internal function, and this test is unwise. Unfortunately, the return type of A^p isn't concretely inferred yet as there are too many possible types that are returned, so I couldn't test for that.

[ViralBShah]

cc @dkarrasch

Also, it's failing the whitespace check.

[jishnub]

The whitespace test seems to have failed identically in #51990 as well, so it may not be related to this PR

[dkarrasch]

I guess one would need some runtimes to make a call? I assume these operations are usually expensive enough such that type instability and dynamic dispatch may not have such a big impact?

[jishnub]

This seems to reduce compile times considerably (not much impact on run-times):

julia> using LinearAlgebra

julia> A = rand(1000, 1000);

julia> @time A^2.0;
 31.874436 seconds (82.36 M allocations: 4.314 GiB, 3.44% gc time, 99.95% compilation time) # master
 25.899704 seconds (58.61 M allocations: 3.101 GiB, 3.29% gc time, 99.94% compilation time) # PR

julia> @time A^20.7; #  in fresh sessions
 51.643851 seconds (112.61 M allocations: 6.862 GiB, 4.14% gc time, 81.14% compilation time) # master
 35.605415 seconds (58.61 M allocations: 4.033 GiB, 3.41% gc time, 72.44% compilation time) # PR

[jishnub]

Bump