Add fragment transactions observing support

[azizutku]

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Description

This MR introduces fragment transaction observability and a helper to retrieve the pending/current fragment, and aligns the project with Java 21.

• New APIs (in Navigator)
  • observeFragmentTransaction(lifecycleOwner, (currentFragment, nextFragment) -> Unit)
  • getPendingOrCurrentFragment()
• Core implementation (in MultipleStackNavigator)
  • Publishes transactions via LiveData of MedusaRequestedFragmentTransaction (uses WeakReference to avoid leaks).
  • Emits before enabling/adding the next fragment so listeners can react to transitions.
• Controller enhancement
  • FragmentManagerController#getCurrentOrStagedFragment(tag) to return staged (pending) fragments before commit.
• Sample app
  • Wires observeFragmentTransaction and logs Previous/Next fragment pairs in MainActivity.
• Build/CI
  • Bumps Java from 17 → 21 in app and medusalib compileOptions, and in GitHub Actions (pull-request.yml, publish.yml).
• Versioning/Docs
  • PUBLISH_VERSION → 0.13.0; CHANGELOG.md updated accordingly.

Motivation and Context

• Provide a first-class, lifecycle-aware way to observe navigation transitions for analytics, logging, and UI side-effects without reaching into FragmentManager.
• Allow querying the pending or current fragment to simplify testing and timing-sensitive flows where transactions haven’t been executed yet.
• Standardize on Java 21 (LTS) across modules and CI for consistency and access to modern tooling.

How Has This Been Tested?

• Unit / Robolectric
  • MultipleStackNavigatorFragmentTransactionObserverTest.kt — observer registration & lifecycle edge cases (no crashes with destroyed lifecycle).
  • MultipleStackNavigatorGetPendingOrCurrentFragmentTest.kt — validates return value across init/start/tab switch/back/reset and pending transactions.
• Instrumented (app)
  • FragmentTransactionObserverTest.kt — ensures notifications on start/back/switch flows and basic ordering.
  • TestExtensions.kt — helpers to force-execute pending transactions and extract readable fragment names.
• Manual
  1. Run sample app; navigate between fragments.
  2. Verify logs like:
     • Destination Changed: <class> - <tag>
     • FragmentTransaction: Previous = <prev>, Next = <next>
  3. Exercise start → back → switch tab; ensure callbacks fire and no crashes occur.
• CI
  • Workflows updated to Java 21; builds and tests pass under the new toolchain.

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.