Add sphere-mongo-3 and sphere-json-3 (the scala 3 version of similarly named modules)

[benko-ct]

• sphere-mongo-core and sphere-json-core are now cross-compiled to scala2/3.
• The Scala 3 part of these modules also include the generic parts, because the Scala 3 autoderivation makes it easier to take care of those parts.
• We decided to drop scala 2.12 support, if anyone needs that, we can add it back

Some guide for the review:

• sphere-mongo-core and sphere-json-core now contain scala-3 folders containing scala3 specific code.
  • That's true for both the main and test folders.
  • The test folders contain all tests from the derivation modules + some new tests

[yanns]

the benchmarks cannot run on scala 3?

[sbrunk]

Scala 3 compilation was disabled before on the benchmarks module. I tried to compile while doing #664 but it uses jsonProduct and mongoProduct that seem to be only available on Scala 2 in the corresponding derivation modules, so I also disabled it for now for Scala 3.

[yanns]

It'd be nice to keep the same API, with the same imports.

I've tried to run the current sphere-json-derivation tests under scala 3, but they do not compile.
All compilation errors that we have here are compilation errors that we will have later in all projects using this lib.
Do you think it'd be possible to achieve the same API.
We did it for sangria, so my first guess is that it's possible?

[benko-ct]

@yanns

Do you think it'd be possible to achieve the same API.

There are 3 categories:

1. jsonProduct / mongoProduct
   • These could theoretically be implemented, but I don't think we want to keep this API. They just seem to be internal methods of deriveJSON/deriveMongoFormat, I'm not even sure why they are used anywhere at all. Otherwise the result should be exactly the same as for deriveJSON/deriveMongoFormat.
   • I'm happy to port all jsonProduct / mongoProduct calls before we move to scala3, then we can keep the same API.
2. typeSwitches. Here I implemented a slightly different API, because scala 2 used FMPP to generate methods for type parameters of 1-22. so it looked like jsonTypeSwitch[SuperType, Subtype1, Subtype2...]
   • The current scala 3 implementation doesn't have a 22 limitation, but instead it takes a tuple for the second parameter, as varargs for types is not a thing in Scala. So it looks like jsonTypeSwitch[SuperType, (Subtype1, Subtype2...)] instead
3. I think there are a few rarely used methods that don't currently have a 1-1 implementation, I will implement these soon.

So the only real change are the typeSwitch calls. This is also not impossible to make backwards compatible I guess. We could just manually create 22 methods, or at least ~10 as we don't use that much anyway, but we have 12 jsonTypeSwitch and 6 mongoTypeSwitch calls, so it's very little effort to port. If we want to cross compile the whole code base, then it would be slightly annoying I guess 🤔

[yanns]

@yanns

Do you think it'd be possible to achieve the same API.

There are 3 categories:

1. `jsonProduct `/ `mongoProduct`
   
   * These could theoretically be implemented, but I don't think we want to keep this API. They just seem to be internal methods of deriveJSON/deriveMongoFormat, I'm not even sure why they are used anywhere at all. Otherwise the result should be exactly the same as for deriveJSON/deriveMongoFormat.
   * I'm happy to port all `jsonProduct `/ `mongoProduct` calls before we move to scala3, then we can keep the same API.

I agree.
We could also do that in the tests and run the same tests with scala 2 and scala 3.

2. typeSwitches. Here I implemented a slightly different API, because scala 2 used FMPP to generate methods for type parameters of 1-22. so it looked like `jsonTypeSwitch[SuperType, Subtype1, Subtype2...]`
   
   * The current scala 3 implementation doesn't have a 22 limitation, but instead it takes a tuple for the second parameter, as varargs for types is not a thing in Scala.  So it looks like `jsonTypeSwitch[SuperType, (Subtype1, Subtype2...)]` instead

We could also change the scala 2 implementation to take a tuple.

3. I think there are a few rarely used methods that don't currently have a 1-1 implementation, I will implement these soon.

👍