Bluetooth: BAP: Add `bt_bap_stream_disconnect`

[Thalley]

Summary

Similar to the bt_bap_stream_connect, the upper layers should be the ones to determine when the CIS should be disconnected.

The main reason for this, is that whether a stream should be connected/disconnected in a given ASE state, depends on what direction the ASE is going.

For example if the ASE is going Enabling [-> Disabling] -> QoS Configured -> Enabling, then if the CIS is already connected, it may not be necessary to to disconnect it.

The lack of knowledge of which direction the ASE is going stems from #92095 where #92095 (comment) explains the issue in more detail.

A workaround in that PR was added to prevent a test case failure, but ideally the CAP Initiator should control when the CIS is connected and disconnected, and how to handle the case where the server may disconnect the stream instead of the client.

Describe the solution you'd like

Move the bt_bap_stream_disconnect to the public BAP API, and do not call that from within the BAP unicast client or server (ASCS).

Samples, shell and tests should be updated to perform this action instead, and an entry into the migration guide should be added.

Alternatives

No response

Additional Context

No response