Updates according to latest SymbolicUtils and TermInterface versions

[apkille]

Merged the CompatHelpers for SymbolicUtils (#37) and TermInterface (#39). Made changes according to latest docs: https://juliasymbolics.github.io/TermInterface.jl/dev/.

[codecov]

Codecov Report

Attention: Patch coverage is 30.00000% with 42 lines in your changes missing coverage. Please review.

Project coverage is 54.70%. Comparing base (ecd9f15) to head (32cf192).
Report is 2 commits behind head on main.

Files	Patch %	Lines
src/QSymbolicsBase/basic_ops_inhomogeneous.jl	10.00%	18 Missing ⚠️
src/QSymbolicsBase/basic_ops_homogeneous.jl	28.57%	10 Missing ⚠️
src/QSymbolicsBase/predefined.jl	40.00%	9 Missing ⚠️
src/QSymbolicsBase/latexify.jl	0.00%	4 Missing ⚠️
ext/QuantumCliffordExt/QuantumCliffordExt.jl	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #42      +/-   ##
==========================================
- Coverage   58.45%   54.70%   -3.75%     
==========================================
  Files          14       14              
  Lines         426      446      +20     
==========================================
- Hits          249      244       -5     
- Misses        177      202      +25     

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

[Krastanov]

This is wonderful, thank you! I made a small change to hopefully fix the Downgrade checks (they basically check whether the oldest permitted versions of dependencies still work -- in this case they should not, given that isexpr did not exist).

[Krastanov]

just a quick explanation for what I am doing with the Downgrade CI runs and why so many compat bound changes are necessary.

There are two things that Downgrade checks for:

• (important) whether you inadvertently have started depending on functionality from your dependencies that is not actually present in the oldest permitted versions of these dependencies (happens if you have been depending on something for a very long time and have slowly permitted newer versions of it to be used and slowly started using newer functionality)
• (less important) whether the oldest versions permitted in compat are still resolvable. They can stop being resolvable if a new dependency was added at some point and that new dependency is compatible only with the most recent versions of the other dependencies. This is not a big deal because without it at worst the following will happen (a) the package manager will tell you a version can not be resolved if you have some other packages installed that clash with these so you will have to create a separate project environment or (b) the package manager will resolve to old versions of this package, which is pretty annoying.

Most software projects do not bother with this type of Downgrade check in their CI, but it provides for less confusion and installation issues for users, so I find it worthwhile.