issymbollike() has been extracted into SymbolicsBase package (Fixes #264)

[LebedevRI]

I'd like to see Symbolics.jl supported in Measurements.jl, but for reasons, the Num type would need to be explicitly allowed on the Measurements.jl side, which will require depending on whatever package providing it.

I've since found the SciMLBase.issymbollike() function, which should answer the question i'm looking for,
but unfortunately, if i add SciMLBase as a dependency of Measurements, to my surprise, we get a cyclic dependency,
because SciMLBase exports issymbollike
from RecursiveArrayTools, which itself depends on Measurements...

By extracting issymbollike() into a new package, on which Measurements.jl could depend,
we avoid dependency cycle.

This, obviously, requires said SymbolicsBase.jl to be made avaliable.
I've put a repo at https://github.com/LebedevRI/SymbolicsBase.jl,
but it needs to be in this org if this is to proceed.

Refs. JuliaPhysics/Measurements.jl#142 (comment)
Refs. JuliaSymbolics/Symbolics.jl#898

Thanks!

[ChrisRackauckas]

Why would this be needed when there's https://github.com/SciML/SymbolicIndexingInterface.jl ? And BasicSymbolic as Unityper?

[LebedevRI]

Thank you for taking a look!

Why would this be needed when there's https://github.com/SciML/SymbolicIndexingInterface.jl ? And BasicSymbolic as Unityper?

Effectively, i'm not saying that it is needed, but only that it appears to provide the answer i'm looking for.
Perhaps you can advise an alternative strategy.

The core problem i need to solve is: given var::Real, how do i determine that it is symbolic?
I.e. i want to distinguish 3 cases: AbstractFloat (good), symbolic (good),
and some arbitrary Real (promote to AbstractFloat).
This is required for https://github.com/JuliaPhysics/Measurements.jl/pull/144/files#diff-594de9d2b4e081df7c7a56ab1dac33d7955109d8e2e54bcb805eda90969dec97R97-R102

It looked like issymbollike() answers that question, alternatively i could check that T<:Num,
but in both cases, there's cyclic package dependency.

[LebedevRI]

Ok, this is indeed not strictly needed, same effect can be mimicked via a @require.
Thank you!