Initial Proposal for getting module support

[tlf30]

As mentioned in #101:

I have hit a major blocking issue in making a simple migration using automation module names.
Shared package between steamworks4j and steamworks4j-server jars. This is an issue because JMS does not allow classes in the same package from two different modules. A solution would be to move everything in the steamworks4j-server jar into its own classpath, such as com.codedisaster.steamworks.server, but because of the use of package private (protected) access between the two jars, this is not possible. Perhaps the best solution would be to merge the two jars into a single jar.

This PR is an initial proposal to get a conversation going. What I changed:

1. The server jar is now merged into the main jar
2. Added separate classpaths for the loaders

The migration path for anyone using the library would be:

1. Remove the steamworks4j-server dependency
2. If referencing the GDX or LWJGL loaders, update the import.

Unit tests pass on my local machine, I have not yet thrown this into a project and done thorough testing yet though. If you like this path forward, I will do more testing before this gets merged.

Thanks,
Trevor

[chengenzhao]

Hi:

Java 22 is about to release in 20 days
and FFM is production ready
so would it be possible to create a separate new project
using jextract to wrap the pure c header of steam sdk, team_api_flat.h?

https://partner.steamgames.com/doc/sdk/api

& then upload this dependencies to maven central repository?

I think this way could be easier to do

Thanks

[tlf30]

@chengenzhao please open your ideas as a separate issue. There is no reason to comment on foreign function api on a PR that has nothing to do with it. I'm not saying that it is a bad idea, just that this was an inappropriate place to comment on it.