GeezerVison

Address PR #987 feedback asking for a clear artifact-name mapping
between jackson-dataformat-msgpack (Jackson 2) and
jackson-dataformat-msgpack-jackson3 (Jackson 3) to reduce upgrade
confusion.

# Conflicts:
#	.github/workflows/CI.yml

main migrated the build to sbt 2 (feb87ef) without sbt-jmh, since
sbt-jmh 0.4.7 has no sbt-2-compatible artifact. This branch's
msgpack-jackson3 JMH benchmarks depend on sbt-jmh, so after merging
main the plugin fails to resolve. 0.4.8 publishes an sbt_2_3 build.

…3 to msgpack-jackson

Co-Authored-By: Claude Fable 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_014ZZUaHusAjVx6SNu4sA42s

…format-msgpack

- msgpack-jackson now hosts the Jackson 3.x integration (artifact
  jackson-dataformat-msgpack, package org.msgpack.jackson3.dataformat,
  Java 17+)
- msgpack-jackson2 hosts the Jackson 2.x integration in maintenance mode
  (artifact jackson2-dataformat-msgpack, package org.msgpack.jackson.dataformat
  unchanged, Java 8+)
- Distinct packages and artifactIds let both integrations coexist on one
  classpath for incremental migration
- Add sbt-jupiter-interface so the Jackson 2 module's JUnit 5 tests actually
  run; they had been silently skipped (0 tests detected) on main
- Fix MessagePackDataformatTestBase lifecycle annotations (JUnit 4 @Before/
  @after on JUnit 5 tests meant setup never ran)
- Restore byte-offset-as-columnNr in Jackson 2 MessagePackParser locations,
  regressed unnoticed in #903 when the deprecated JsonLocation constructor
  was replaced

Co-Authored-By: Claude Fable 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_014ZZUaHusAjVx6SNu4sA42s

0.17+ upgrades to JUnit 6, which requires Java 17; the JDK 8 CI lane failed
compiling msgpack-jackson2 tests against junit-jupiter-api 6.0.3 (class file
version 61). 0.15.2 stays on JUnit 5.14, and the module's explicit
junit-jupiter 5.14.4 dependency wins resolution. Verified by forking the
tests onto a real JDK 8.

Co-Authored-By: Claude Fable 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_014ZZUaHusAjVx6SNu4sA42s

Restructure the module layout per PR review feedback (JLBP-6): instead of
renaming the Jackson 2 artifact to jackson2-dataformat-msgpack and giving
Jackson 3 the unqualified jackson-dataformat-msgpack artifactId, rename the
Maven coordinates and the Java package together:

- Jackson 2 (msgpack-jackson): keeps org.msgpack:jackson-dataformat-msgpack
  and the org.msgpack.jackson.dataformat package, exactly as 0.9.x. Existing
  users need no changes. Maintenance mode: Jackson 2.x bumps and bug fixes only.
- Jackson 3 (msgpack-jackson3): published as
  org.msgpack.jackson3:jackson-dataformat-msgpack with the
  org.msgpack.jackson3.dataformat package, mirroring Jackson's own 2->3
  groupId rename (com.fasterxml.jackson.dataformat -> tools.jackson.dataformat).

Because the two artifacts share the same fully-qualified class names in
neither direction, they can coexist on one classpath, and dependency
resolution can never silently replace the Jackson 2 classes with Jackson 3
ones (or vice versa). The 1.0.0 version bump is no longer needed.

Both sbt subprojects now share the module name jackson-dataformat-msgpack,
so the Jackson 3 project overrides outputPath to keep sbt 2 build output
directories from overlapping.

Co-Authored-By: Claude Fable 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01C4Sp7Q2urgnYfuNXK2fVFm

)

JmhPlugin adds jmh-core, jmh-generator-bytecode and jmh-generator-reflection to
libraryDependencies without a configuration, so enabling it on msgpack-jackson3
published them as compile dependencies of jackson-dataformat-msgpack, inherited
by every consumer along with jopt-simple, commons-math3 and ASM. The released
org.msgpack:jackson-dataformat-msgpack POM has no such entries.

Move src/jmh into msgpack-jackson3-benchmark, which depends on msgpack-jackson3
and is not published. This is also how sbt-jmh recommends laying out benchmarks,
since the code generator needs a project of its own.