build: add spotless, checkstyle, and enforcer plugin configuration

[wombatu-kun]

Summary

• Add checkstyle.xml ported from lance-spark.
• Add .editorconfig for cross-IDE consistency (UTF-8, LF, 4-space Java,
  2-space XML/YAML, tab Makefile, max_line_length = 100).
• Wire spotless-maven-plugin 2.43.0 with google-java-format 1.19.2
  (GOOGLE style), importOrder = org.apache.flink,,javax,java,#,
  removeUnusedImports, and the short Apache 2.0 license header.
  Invoked explicitly: mvn spotless:check / mvn spotless:apply.
• Wire maven-checkstyle-plugin 3.3.1 with configLocation=checkstyle.xml,
  failsOnError=true, violationSeverity=warning. Invoked explicitly:
  mvn checkstyle:check.
• Wire maven-enforcer-plugin 3.4.1 with requireMavenVersion 3.6.3 and
  banDuplicatePomDependencyVersions, bound to the validate phase.

Spotless and Checkstyle are intentionally not bound to a build phase
in this PR. They will be wired into the validate phase in the follow-up
PR chore: apply initial spotless formatting, which also runs
mvn spotless:apply against the existing 31 .java files. Splitting the
work this way keeps the configuration PR small and reviewable, and the
formatting PR mechanical and trivially reviewable.

[wombatu-kun]

Hi @fightBoxing, when you have a moment, could you take a look at this one?

This PR only adds configuration and does not bind Spotless or Checkstyle to any build phase, so merging it cannot change mvn package or break CI. The plugins stay opt-in and are run explicitly via mvn spotless:check / mvn checkstyle:check until the follow-ups wire them in. The diff is small (3 files, +283/-0): .editorconfig, checkstyle.xml (ported from lance-spark so the formatting stays consistent across the lance-format projects), and the plugin declarations in pom.xml.

It is intentionally the first link in a small, reviewable chain: #23 sets up the config, #24 applies the initial spotless:apply over the existing sources, and #25 adds the Makefile and CI checks. Landing #23 first unblocks the rest and gives the project a shared formatting baseline, which keeps future diffs clean and lowers the barrier for new contributors.

There is also a merge-order angle with #48: since that PR turns the root pom.xml into a parent pom and moves plugin management into dependencyManagement, landing #23 first lets the Spotless, Checkstyle, and Enforcer config settle into the build before the restructure, instead of having to re-add it into the new parent layout afterwards. If you would rather merge the module restructure first, I am happy to rebase #23 on top of #48 instead, whichever order you prefer.