Add AutoMooncake type

[willtebbutt]

Checklist

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

Additional context

AutoTapir needs to be deprecated in favour of AutoMooncake, because Tapir.jl has been renamed to Mooncake.jl.

I could do with some advice on the appropriate way to deprecate AutoTapir -- should I just add the constructor to the legacy.jl file, or is there something else that I should do?

[ChrisRackauckas]

I could do with some advice on the appropriate way to deprecate AutoTapir -- should I just add the constructor to the legacy.jl file, or is there something else that I should do?

@deprecate AutoTapir AutoMoonCake?

[gdalle]

Can we have a default setting so that people don't need to dig into the Mooncake.Config docs? Like AutoMooncake(; config=nothing)?

[willtebbutt]

We could do that. I'd prefer to prevent people from writing AutoMooncake() -- they should at least have to write AutoMooncake(; config=nothing) -- in order to ensure that people are aware that they have some configuration options.

[gdalle]

Sounds good, let's do that. As a user of ADTypes it's always a bit painful to go grab a specific type from a package to configure backends (like AutoChainRules(; config=Zygote.ZygoteRuleConfig()))

[gdalle]

Ready for review?

[willtebbutt]

Yes, go for it.

[gdalle]

Thanks for this contribution! Most of my remarks are esthetics, fundamentally it is good to go