Add Symbol -> AbstractADType mapping

[gdalle]

In https://github.com/gdalle/DifferentiationInterface.jl/issues/319, @MilesCranmer proposed a mapping from package Symbols to AbstractADTypes. While this mapping is not strictly necessary, it makes things easier for interfacing with Python. Here's an experimental PR doing just that, let's see what people think.

[!WARNING] I don't want to encourage the use of Symbols, since ADTypes.jl is precisely there to avoid their shortcomings. Hence the strongly-worded docstring.

Checklist

• [x] Appropriate tests were added
• [x] Any code changes were done in a way that does not break public API
• [x] All documentation related to code changes were updated
• [x] The new code follows the contributor guidelines, in particular the SciML Style Guide and COLPRAC.
• [x] Any new documentation only uses public API

[ChrisRackauckas]

I'm at least not opposed with the proper warnings on it.

[gdalle]

I worded the docstring as follows, let me know if we should make it stronger. I also ensured it is displayed at the very bottom of the API reference page.

    ADTypes.Auto(package::Symbol)

A shortcut that converts an AD package name into an instance of [`AbstractADType`](@ref),
with all parameters set to their default values.

!!! warning
    This function is type-unstable by design and might lead to suboptimal performance.
    In most cases, you should never need it: use the individual backend types directly.

[ChrisRackauckas]

That's probably sufficient.

[MilesCranmer]

Looks pretty good to me :+1:

[gdalle]

Looks pretty good to me 👍

Can you try it out in your SymbolicRegression.jl use case before we merge, to be sure we didn't miss something?

[MilesCranmer]

Cool, confirmed it works! :)

and, in the Options constructor (type unstable on purpose; it's just an entrypoint function that the user will then pass to the actual search)

[MilesCranmer]

Thanks!

(Registering this soon would be great if possible 😁 I'm eager to put this into SymbolicRegression.jl/PySR)

[gdalle]

done!