build: publish AAR + sources via maven-publish for JitPack consumption

[Devild007]

Summary

• Add the maven-publish plugin to featbit-client and featbit-client-android, and declare a MavenPublication("release") on top of the existing AGP singleVariant("release") { withSourcesJar() } block
• Populate coordinates from GROUP + VERSION_NAME in gradle.properties (co.featbit:*:0.1.0-SNAPSHOT locally)
• Prefer JitPack's VERSION environment variable over the gradle property at build time so the file names on disk match the tag JitPack is building (JitPack looks up <artifact>-<tag>.aar, not <artifact>-0.1.0-SNAPSHOT.aar)
• Enrich generated POMs with name, description, url, licenses (Apache-2.0), and scm blocks — accepted by JitPack today, and by Maven Central or a private registry if the artifact is ever republished
• Add jitpack.yml pinning openjdk17 (matching the existing CI workflow) and pointing JitPack at the two-module publishToMavenLocal invocation
• Update README.md's Installation section to document the real JitPack coordinate (com.github.Fluent-Health.featbit-android-sdk:<module>:<tag>) instead of the earlier co.featbit:featbit-client:<version> placeholder

Why

Consumers cannot pin a version of this SDK today: they either take a source-level git submodule dependency, drop a locally-built AAR into libs/, or fall back to the placeholder coordinate. None scale past a single consumer. Publishing via JitPack costs no additional infrastructure — a git tag on this repository is enough — and keeps the door open for Maven Central or a private registry later without changing consumer code.

Verified locally

• ./gradlew :featbit-client:publishToMavenLocal :featbit-client-android:publishToMavenLocal publishes co.featbit:featbit-client:0.1.0-SNAPSHOT and co.featbit:featbit-client-android:0.1.0-SNAPSHOT with AAR + sources jar + POM to ~/.m2
• VERSION=v0.1.0 ./gradlew :featbit-client:publishToMavenLocal :featbit-client-android:publishToMavenLocal simulates a JitPack build for tag v0.1.0: the files come out as featbit-client-v0.1.0.aar etc. and every POM entry (parent module, cross-module transitive) declares the same version
• featbit-client-android's POM correctly declares a compile-scope dependency on featbit-client at the same version — JitPack rewrites the group to com.github.Fluent-Health.featbit-android-sdk at serve time as part of its multi-module handling

Consumer wire-up once the first tag lands

// settings.gradle.kts (in a consumer project)
dependencyResolutionManagement {
    repositories {
        mavenCentral()
        maven { url = uri("https://jitpack.io") }
    }
}

// build.gradle.kts (in a consumer module)
dependencies {
    implementation("com.github.Fluent-Health.featbit-android-sdk:featbit-client:v0.1.0")
    // Optional Android lifecycle glue, depends on `featbit-client` transitively.
    implementation("com.github.Fluent-Health.featbit-android-sdk:featbit-client-android:v0.1.0")
}

Out of scope

• A dedicated publish job in CI. JitPack builds on demand per tag, so no locally-driven publish workflow is required. If Maven Central becomes the target later, GPG signing and a release workflow can be added at that point
• Version-bump automation. VERSION_NAME in gradle.properties is only the local fallback; a real release is a git tag, which is the JitPack contract

Test plan

• ./gradlew :featbit-client:publishToMavenLocal :featbit-client-android:publishToMavenLocal succeeds; inspect ~/.m2/repository/co/featbit/…/*.pom for metadata
• VERSION=v0.1.0 ./gradlew :featbit-client:publishToMavenLocal :featbit-client-android:publishToMavenLocal produces -v0.1.0 artifact names and version entries in every POM
• After merge, tag v0.1.0 on this branch and request the artifact from JitPack in a scratch Android project; confirm assembleDebug resolves both modules including the transitive dependency