Modify OptionContainer to use secondary appearance

### What is the problem or limitation you are having?

Toga's OptionContainer widget can be placed anywhere in a content layout. You can place an OptionContainer as part of a page; you can put content vertically above and below an OptionContainer in a layout, and so on.

However, Android and iOS style guides both dictate that the widgets we're using for OptionContainers should only be used as the top level widget. It should be used as a controller for the entire app, not just a part of an app window.

The current rendering of an OptionContainer is incompatible with arbitrary usage of an OptionContainer in a layout

### Describe the solution you'd like

Both iOS and Android provide for a different rendering of OptionContainers - Android Material calls these [secondary tabs](https://m3.material.io/components/tabs/guidelines); iOS has a [UISegmentedControl](https://developer.apple.com/documentation/uikit/uisegmentedcontrol?language=objc). These layouts are a lot more like desktop-style tab controls - they're at the top of the page, and can be wrapped around parts of content on a page.

We should modify OptionContainer on iOS and Android to use a rendering closer to the desktop rendering (i.e., "top tabs", using the secondary appearance). This allows end users to put an OptionContainer anywhere they want in a layout (including potentially nesting OptionContainers inside OptionContainers).

The API for OptionContainer won't change.

### Describe alternatives you've considered

No real option; the current OptionContainer is broken for any usage other than being the top-level container.

### Additional context

See discussions on #4354, #4271 and #4059 for context.

This will be a backwards incompatible change, as any existing mobile app that uses OptionContainer to provide "bottom of page" tabs will change behavior. However, the *functionality* of the app won't change if a user uses an OptionContainer as the root container of their app, so we don't need to preserve a path for the existing implementation. The behavioral change should be flagged in release notes, though.

The underlying widget implementations and test probes should be retained; these will be useful when implementing #4299.

Review discussions #4354, #4271, and #4059, then inspect the existing Android and iOS OptionContainer widget implementations and their test probes. Done means both platforms use a desktop-like secondary/top-tab appearance without changing the API, the existing probes are retained, and the backwards-incompatible behavior is recorded in release notes.

Written by the indexing model from the issue text.