Bluetooth: host: l2cap: send only 1 credit

The API doesn't allow the stack to make any guarantees about the number of
available buffers that the app has.

Only send 1 credit at a time, as that is the only guarantee the stack can
give to the peer.

We can send MTU/MPS's worth of credits once we have acquired an SDU buffer
from the application (that is, on the first PDU of the SDU). Though we
still have to cap that to the buffer size we have just acquired.

------

The testcase added here shows a scenario where the relationship
between the number of credits and the number of available buffers does not
hold true any more:

In this test, the app only has one buffer in its pool.

The central will queue SDUs that are bigger than the stack's
buffers (so the user allocator is necessary) but lower than the
channel's MTU.

The device receiving the SDU keeps a reference to the buffer before
returning from the `recv` callback. It releases that reference after a
small delay.

The central will still have credits, so it will queue another SDU, but the
peripheral will not be able to receive the next SDU (as the allocator will
fail) and will close the channel.

To see the test fail, just revert the `l2cap.{c,h}` changes.

Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>