Switch from Requires.jl to package extensions

[kbarros]

Remove Requires.jl in favor of Julia 1.9 "package extensions". Two motivations are (1) it becomes possible to specify [compat] entries for weak dependencies (e.g., we can enforce recent versions of GLMakie), and (2) it becomes possible to use PrecompileTools.jl which I'm hoping can significantly reduce TTFX in the common cases.

I hit a few snags in making this PR:

• Unlike Revise.jl, package extensions can only add methods to existing functions, they cannot create new functions in the base package. The workaround seems to be defining "stub" functions in the original Sunny module, and adding methods in the extension packages.
• It gets inconvenient to have to define a new stub for each private function. I used a hack to create a Sunny.Plotting module which will store the private plotting functions.
• The Documenter.jl @autodocs feature is not finding doc strings for functions defined through package extensions. https://github.com/JuliaDocs/Documenter.jl/issues/2124#issuecomment-1683268037. The workaround seems to be creating @docs blocks that list each extension function explicitly.

This PR also makes DynamicPolynomials a required dependency of Sunny again. That choice increase the time for using Sunny from about 1.15s to 1.3s-ish, and most of that increase comes directly from using DynamicPolynomials. I think we need to do it though (or roll our own dynamic polynomials) because this is the most natural way to specify classical polynomials of commuting spin variables. Maybe we can win back load-time efficiency in the future by, e.g., adding precompile statements.

I think it's ready to merge if @ddahlbom gives a thumbs up.

[Lazersmoke]

Still not sure about the Unicode here

[ddahlbom]

I have to admit I'm a bit confused about the hack you used @kbarros. Perhaps we can chat about it at some point. But I everything looks good to the degree that I understand it.

@Lazersmoke Is your primary concern about users in some situation where they can't display unicode? How common do you think that will be? (I guess remote work on a terminal could be a problem.)

I can't think of a more satisfying alternative at the moment. From an interface standpoint, the symbols are kind of "magical" and unique in the interface, so it makes sense that they'd be the only example of unicode that Sunny exposes. I don't think we want to take over regular S and O.

We could provide a non-unicode synonym that's uglier, but usable in a basic terminal. Maybe Ss or Os, to emphasize that they're vectors.

In any case, from my perspective it's good to merge.

[kbarros]

Still not sure about the Unicode here

The Unicode is being removed from the public interface. Maybe you are noticing that I removed the links to the historical symbols in versions.md? But this PR actually removes those symbols from the public API.

Future sunny will no longer use \scrS and so forth to denote local operators. We will only need DynamicalPolynomials to figure out how to convert a polynomial of commuting spin variables to a linear combination of Stevens functions (i.e. decompose in spherical harmonics). And that mapping will only be to support model systems in large-S mode. It's not implemented yet, but that is the motivation for keeping DynamicPolynomials while removing things from the public interface. (In general, less exported stuff gives us more flexibility later)