refactor: restructure as composite build (library + gradle-plugin as standalone builds) #38

Background

Currently library and gradle-plugin are subprojects of a single root Gradle build. This works fine for the main build but creates an inception problem: gradle-plugin cannot apply itself or be consumed by a sibling docs/ build without publishing to Maven Local first.

Proposed approach

Restructure as a composite build:

markflow/
  library/          # standalone Gradle build
  gradle-plugin/    # standalone Gradle build, includeBuild("../library")
  docs/             # standalone Gradle build, pluginManagement { includeBuild("../gradle-plugin") }
  build.gradle.kts  # root composite: includeBuild("library") + includeBuild("gradle-plugin")
  settings.gradle.kts  # root: no subprojects, just includeBuild declarations

Benefits

• docs/ can apply the plugin directly via includeBuild — no Maven Local publish step needed
• Each module is independently buildable and composable
• ./gradlew build at the root still builds everything via composite
• Clean dogfooding: docs/ lints the repo's own *.md files on every build
• Correct long-term architecture for a library + plugin pair that will be published separately

Implications

• CI workflows referencing :gradle-plugin:* task paths need updating to -p gradle-plugin or composite task names
• Version coordination: git-versioning plugin reads from git so both modules pick up the correct version independently
• IDE setup: both modules visible as separate Gradle projects, or as one composite
• gradle-plugin dependency on library changes from project(":library") to includeBuild substitution

References

Explored during PR #37 — the docs/ dogfooding attempt hit the Gradle composite build limits of the current subproject layout.