le_audio: Don't block main thread with suspend request call

There is possibility that due to race in stream suspend Audio framework
may interrupt reporting stack about suspension with call to stack (Bluetooth
main thread).

Due to this race a Bluetooth Main Thread may remain waiting for streamSuspended
response from provider and not let suspend (stack part) Audio Framework.

Not waiting for finishing suspend handler (by not setting promise value
for future wait) allows Audio Framework caller schedule bind once on
Bluetooth Main Thread and be finished after stack report about
suspension would be finished. After such scenario stack will be in
proper state (audio_sender_state_ in state IDLE/RELEASING/SUSPENDING)
and call from Audio Framework will be just skipped.

Tag: #feature
Bug: 287890133
Test: atest bluetooth_le_audio_test bluetooth_le_audio_client_test
Change-Id: I12f7890dc03d0600378ce1e00e06c04fd214663c