feat: Refactor configuration to use Jakarta Config in lyo-server-common

[berezovskyi]

Introduces a new lyo-server-common module to handle configuration property retrieval using the MicroProfile Config (Jakarta Config) API. This replaces the previous manual priority logic (Env > System > Context) with the standard Config precedence (System > Env > Properties) while maintaining a fallback to ServletContext init parameters.

Changes:

• Created server/lyo-server-common module.
• Added microprofile-config-api dependency.
• Implemented LyoAppConfiguration utility class.
• Added unit tests for LyoAppConfiguration.
• Registered module in parent POMs.

This refactoring aligns with Jakarta Config standards and separates server-specific configuration logic from core modules.

This PR supersedes #220

Checklist

• This PR adds an entry to the CHANGELOG. See https://keepachangelog.com/en/1.0.0/ for instructions. Minor edits are exempt.
• This PR was tested on at least one Lyo OSLC server (comment @oslc-bot /test-all if not sure) or adds unit/integration tests.
• This PR does NOT break the API
• Lint checks pass (run mvn package org.openrewrite.maven:rewrite-maven-plugin:run spotless:apply -DskipTests -P'!enforcer' if not, commit & push)

[berezovskyi]

@Jad-el-khoury major breaking change when aligning configuration with Jakarta Config is that we will no longer have different prop prefixes.

Before:

• prop port
• env var LYO_PORT
• system prop and context param org.eclipse.lyo.oslc4j.core.servlet.port

After:

• prop lyo.port (could be eclipse.lyo.port but I don't see lyo to be a too risky of a prefix)
• env var LYO_PORT
• system prop and context param lyo.port

The breaking change would affect:

• Existing users and Lyo Designer - a simple renaming would fix things
• Multi-tenant users of Lyo, hosting multiple OSLC apps as Lyo REST servers using the same servlet container. Starting with Lyo 7, Lyo will no longer provide means to set props on a global level for different WARs thanks to the package prefix. This aligns with the move in the rest of the Java industry away from one-container-to-rule them all since ca. 10 years ago.

We can probably add some legacy fallback to support the legacy prefixes but I would suggest just to drop it.

[berezovskyi]

public record LyoAppConfiguration(String baseUrl, String servletPath, Set<String> corsFriends) {}

could now be replaced by

@Configuration
@ConfigMapping("eclipse.lyo")
interface LyoAppConfiguration {
    @ConfigName("getBaseUrl")
    string baseUrl();

    @ConfigDefault("8080")
    int port();

    @ConfigName("cors.friends")
    @ConfigConverter(IOThreadsConverter.class)
    Set<string> corsFriends();
}

or more direct injections of the variables.