Bluetooth: Host: Refactor legacy adv creation

This fixes #78721 which was introduced in PR #44686, which changed (and
renamed) `adv_new_legacy`/`adv_get_legacy` to return an existing
`bt_dev.adv` if it existed. This caused a problem, where the existing
adv then would be used to start advertising, and if this fails (because
the adv is already advertising, for instance), `bt_le_adv_start` would
erroneously delete the adv, making the host lose the context for the adv
which still is advertising.

Before PR #44686, this would not happen, because `bt_le_adv_start` would
return early when `adv_new_legacy` returned `NULL` and never reach the
delete call.

I have refactored this to make responsibilities a bit more clear:
`adv_create_legacy` now does 1 thing: create an ext adv and assign as
the legacy advertiser. This mirrors `bt_le_adv_delete_legacy` which does
the opposite. I have implemented error codes to match the behavior that
PR #44686 was made to implement.

Signed-off-by: Ludvig Jordet <ludvig.jordet@nordicsemi.no>