[material_ui] Add tertiary tap callbacks to InkResponse and InkWell

[Ahtsham0715]

Ported from flutter/flutter#191971, which was opened against flutter/flutter before I noticed the Material code freeze (flutter/flutter#188444). That PR has been closed in favour of this one.

GestureDetector exposes onTertiaryTapDown, onTertiaryTapUp and onTertiaryTapCancel, but InkResponse/InkWell only forward the primary and secondary button callbacks. That means a middle click on an InkWell — the usual way to open a link in a new tab or window on desktop and web — can't be handled without wrapping the widget in a second gesture detector, which then has to be reconciled with the ink splash.

This PR adds the three tertiary callbacks to InkResponse and InkWell, mirroring the existing secondary button plumbing:

• The pressed highlight and ink splash start on tertiary tap down and are resolved on tap up or cancel, exactly as they are for the secondary button.
• The tertiary button is only listened for when onTertiaryTapDown or onTertiaryTapUp is non-null, so widgets that don't opt in behave exactly as before (no splash on middle click, same as today).
• onTertiaryTapCancel alone does not enable the button, which matches how onSecondaryTapCancel already behaves.

There is no onTertiaryTap because TapGestureRecognizer/GestureDetector don't have one; onTertiaryTapUp is the completion signal for that button.

This follows the approach suggested in the issue: a specific widget with a concrete use case, rather than a general reworking of the button callback pattern.

Tests added to packages/material_ui/test/ink_well_test.dart:

• InkWell tertiary tap test — verifies the down/up ordering on a completed middle click, and down/cancel when the pointer is dragged away.
• InkWell tertiary tap highlights only when a tertiary callback is defined — verifies the pressed highlight is raised and lowered on a tertiary press when a tertiary callback is supplied, and that a tertiary press is ignored when one is not.

A pending changelog entry is included with a minor version bump, since this is additive API.

Fixes flutter/flutter#129058

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter.
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I followed the version and CHANGELOG instructions, using semantic versioning and the repository CHANGELOG style, or I have commented below to indicate which documented exception this PR falls under.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under.
• All existing and new tests are passing.

[gemini-code-assist]

Code Review

This pull request adds support for tertiary (middle-click) tap gestures (onTertiaryTapDown, onTertiaryTapUp, and onTertiaryTapCancel) to InkResponse and InkWell, along with corresponding tests and a changelog entry. The reviewer suggests expanding the test coverage to verify that the highlight is correctly shown when only onTertiaryTapDown or both tertiary callbacks are provided, rather than only testing onTertiaryTapUp.

[gemini-code-assist]

This test is great for verifying that highlights are shown for tertiary taps only when a callback is provided. However, it only checks for the presence of onTertiaryTapUp. The logic in _tertiaryButtonEnabled also enables tertiary tap handling if onTertiaryTapDown is provided.

To make this test more comprehensive, consider parameterizing it to check that the highlight is correctly shown when:

1. Only onTertiaryTapUp is provided.
2. Only onTertiaryTapDown is provided.
3. Both are provided.
4. Neither is provided (as is already tested).

This would provide stronger guarantees about the correctness of the enabling logic.