This PR replaces Lightbend Config with sconfig, for rationale please see discussion at #2186.

99% of the changes were entirely mechanical due to the fact that aside from the package, sconfig is entirely source compatible with lightbend config while also keeping the same behaviour. More specifically

• With regards to Java, aside from com.typesafe.config to org.ekrich.config the source code is 100% the same. That means for our Java users, if they ever programmatically used the typesafe config all they need to do is to change an import
• With regards to Scala, although sconfig is source compatible with lightbend config (again aside from com.typesafe.config to org.ekrich.config), newer versions of Scala have deprecated auto unary tupling and auto unary untupling, i.e ConfigFactory.empty vs ConfigFactory.empty() and v.valueType() vs v.valueType. Although we can technically make our Scala codebase compile without any changes of adding/removing (), this would involve suppressing deprecation warnings so I don't see any benefit in doing so.
• The migration steps outlined at https://github.com/ekrich/sconfig?tab=readme-ov-file#migrating-an-existing-lightbendconfig-project-to-sconfig worked perfectly (we didn't even need to add scalafix since Pekko project already has it) however one thing to note is that it only works for Scala source files, Java will need to be migrated separately but as said earlier the migration for Java is even easier (changing a single root package name). A single grep is all that Java users would need
• Most of the effort was actually in generating the MiMa filters, there was a lot of them....
• No tests need to be changed at all, everything just passed after the mechanical changes and the codebase was compiled. Even Pekko tests which were specifically testing for behaviour of Lightbend Config passed without changes
• The only non mechanical change needed was an update to the paradox doc apiMappings, this has been noted in the PR so its clear to see.

I still need to do a manual pass to check the documentation generation works fine (paradox compiled without issues but I will manually generate it locally to double check that the links to sconfig docs work as expected). Due to the large number of changes if you want to manually review the PR I would recommend checking out the branch and doing it locally.

To keep the discussions on topic, if you have questions on the premise of the PR (i.e. using sconfig in the first place) then please use the discussion thread at #2186. On the other hand if you have specific discussion regarding the implementation in this PR then feel free to comment