Use macros to fix stack overflow when deriving for local classes

[mrdziuban]

Fixes #2263
Supersedes and closes #2278 if merged

@hamnis this is an alternate approach to what I did in #2278. By using macros for derivation we can match on the Mirror and extract the MirroredLabel, MirroredElemLabels, and MirroredElemTypes types without causing a stack overflow.

There are two caveats (the tests will fail if either of these things change in the future):

1. Any methods that call the macros must mark their Mirror.Of as inline
2. Any parameters derived from the Mirror in the macro must be passed by-name, e.g. fromProduct in ConfiguredDecoder.ofProduct and ConfiguredEncoder.ofSum

[hamnis]

I found this easier to understand

[hamnis]

Letting @zarthross decide to merge

[zarthross]

I would love to be shown wrong on this, but removing this method concerns me.

I know that when you use inline on a private method, (the original derived below calls this of), that there is a public accessor created, in this case it should be inner$of.

If we have some library, lets call if A that used theses macros, and some end user app called B.
What happens if circe is updated to ofProduct, built a built with of... and B updates the version of circe to no longer include inner#of? I feel like we will get a NoSuchMethodError in application B?

I'm worried we'll have a similar problem to #2089

[zarthross]

Not sure why mima doesn't catch this situation....

[mrdziuban]

Wow I didn't know about that behavior but you're definitely right, I confirmed in a fresh project. I'll put the of methods back

[mrdziuban]

Oh wait actually, just putting of back doesn't fix the issue. The inline$of method only exists in the bytecode if of is called from an inline method, so we could also need to add a dummy inline method that still calls it. Given that, what do you think the best course of action is @zarthross?

[zarthross]

Yeah, this is certainly an awkward part of scala3 inlines... we could try adding a private method with the name inline$of? I'm not sure if scala 3 will allow that, or we could try a dummy inline method as you suggested... we'll just have to try a few things and check the generated bytecode....

[mrdziuban]

I ended up adding inline$of methods. They can't be private otherwise they cause a java.lang.IllegalAccessError instead of a binary incompatibility, but I made them private[derivation] and marked them as deprecated

Some changes were needed, dissmissed to avoid premature merge

[zarthross]

Thanks for the hard work on this!