Add custom format comparator support to AdaptiveTrackSelection

[AndyWangLYN]

Summary

Adds optional custom format ordering for AdaptiveTrackSelection so apps can influence
ABR selection priority beyond bitrate-only ordering. While default behavior remain unchanged

This PR is refined version of the PR: #3064 in which I received comments about track format sorting. Intend to close above PR if this one is deemed good eventually.

What changed

• Added AdaptiveTrackSelection.Factory#setTrackFormatComparator(Comparator<Format>)
  to allow custom format ordering via the factory.
  • Added protected final getTrackFormatComparator() on Factory so subclasses that
    override createAdaptiveTrackSelection() can access the configured comparator.
  • Added a new protected constructor on AdaptiveTrackSelection accepting a
    Comparator<Format>, enabling subclasses to pass a comparator directly.
  • Updated switch-up/switch-down direction logic in updateSelectedTrack to use index
    comparison instead of bitrate comparison, so it works correctly with any comparator
    (lower index = higher priority).
  • Extracted DEFAULT_FORMAT_COMPARATOR as a named constant in BaseTrackSelection.
  • Updated TrackSelection and field Javadoc to say "selection order" instead of
    "decreasing bandwidth order".

Why

The current implementation always prioritizes higher bitrate. This makes it difficult to
express developer-defined rules (e.g. a quality score ranking) without subclassing and
duplicating ABR logic. These hooks allow custom ordering without touching core ABR
switching behavior.

Testing Done

• Unit test for comparator and default behavior

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[AndyWangLYN]

hey guys can I get some feedback on this PR? Any feedback can do. Very much appreciated! @tonihei @oceanjules

[AndyWangLYN]

Also raised a question regarding this: #3077

[AndyWangLYN]

Hey ready for another review whenever you have the time. Thank you @tonihei

[AndyWangLYN]

Mind sharing some more insights on this PR? I really believe this could be helpful, especially in mixed codec (bitrate != video quality) cases and could be beneficial (ran into this issue during my work). Thank you! @tonihei