bluetooth: host: Use critical section when making channel ready to send

A public API call that sends ACL data — for example, `bt_gatt_notify` —
can be invoked from a preemptive thread context. This API, in turn,
calls the `raise_data_ready` function, which adds an L2CAP channel to
the `l2cap_data_ready` list.

The atomic variable used to create a critical section around
`l2cap_data_ready` did not work, because a preemptive thread can be
pre-empted at any time. This means that regardless of the `atomic_set`
result, we cannot trust it — the thread could be preempted after the
call, and the atomic variable state could be changed (specifically by
the TX processor in this case). The same issue applies to
`bt_conn_data_ready`, which is called next.

When making an L2CAP channel ready for sending data, we need to use a
critical section when appending a channel to the `l2cap_data_ready`
list. The same applies to the `conn_ready` list.

Since cooperative threads can only be rescheduled explicitly, we must
ensure there are no rescheduling points when accessing either the
`l2cap_data_ready` or `conn_ready` lists.

For `l2cap_data_ready`, this occurs in `get_ready_chan`, which is called
from `l2cap_data_pull`, which in turn is called by the TX processor. For
`conn_ready`, it occurs in `get_conn_ready`, which is also called from
the TX processor. Both functions have no rescheduling points when
working with their respective lists, so they do not require a critical
section.

This change removes the atomic variables previously used to create a
critical section for both lists, as they were ineffective. Instead,
`k_sched_lock`/`k_sched_unlock` are used where code may be executed from
a preemptive thread context. The `sys_slist_find` function is used to
check whether a channel or connection is already in the corresponding
list.

Fixes #89705

Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>