Reconsider symbol names used in algorithm specification

[leburgel]

At the moment, we offer the possibility of configuring all algorithms using lower-case symbols (e.g :halfinfinite, :linsolver, :gmres...). However, since MatrixAlgebraKit allows using symbols for algorithm specification, it makes sense to just reuse their symbols without introducing new ones (implemented in #364). The MatrixAlgebraKit algorithm symbols exactly match the algorithm struct names, including capitalization. The downside is that we'll now have a mixture of different capitalizations in our symbol conventions, which can make things (more) confusing.

One solution would be to adopt the MatrixAlgebraKit convention here, and just use symbols that are exactly the algorithm struct names where possible. This makes all the more sense for symbols indicating algorithms defined outside of PEPSKit (e.g. :gmres which specifies KrylovKit.GMRES, we could avoid introducing a new symbol by just using :GMRES instead`.

The question is then if we should also capitalize the symbols linked to internal PEPSKit algorithms. We probably don't want to use the full :HalfInfiniteProjector, but we could switch to :HalfInfinite. I think this is only worth it if it would be less confusing for users. If none of the capitalized symbols actually match the algorithm struct names, then it's probably not worth to change them.

[lkdvos]

I would actually also be okay with :HalfInfiniteProjector, I don't mind typing just a few extra characters typically, and certainly not if it makes the links more obvious.

[leburgel]

Just matching symbols to struct names might actually be the most consistent solution now, especially since this is how it already works for certain parts of the algorithm specification. If no one opposes, I can give this a go.

[pbrehmer]

I would also prefer matching symbols to struct names, even in the longer cases such as :HalfInfiniteProjector. Although there are cases where I'm not sure what we would do: for example for the truncation schemes, we call the symbols based on the short-hand functions, e.g.:

* `trunc::Union{TruncationStrategy,NamedTuple}=(; alg::Symbol=:$(Defaults.trunc))` : Truncation strategy for the projector computation, which controls the resulting virtual spaces. Here, `alg` can be one of the following:
    - `:fixedspace` : Keep virtual spaces fixed during projection
    - `:notrunc` : No singular values are truncated and the performed SVDs are exact
    - `:truncerror` : Additionally supply error threshold `η`; truncate to the maximal virtual dimension of `η`
    - `:truncrank` : Additionally supply truncation dimension `η`; truncate such that the 2-norm of the truncated values is smaller than `η`
    - `:truncspace` : Additionally supply truncation space `η`; truncate according to the supplied vector space 
    - `:trunctol` : Additionally supply singular value cutoff `η`; truncate such that every retained singular value is larger than `η`

Translating truncrank to TruncationByOrder doesn't feel very clear to me. So maybe in these cases I would just leave the symbols lowercase, but I'm not sure.

[leburgel]

I think it's fine to keep the truncation strategy symbols that directly correspond to MatrixAlgebraKit methods. However, I would either replace :fixedspace and :sitedependent by :FixedSpaceTruncation and :SiteDependentTruncation, or introduce new lower-case shorthand methods and then match the symbols with those. Otherwise we still introduce new names, which we should avoid.

[pbrehmer]

I think I'd be in favor of :FixedSpaceTruncation and :SiteDependentTruncation in this case.