Bluetooth: Add bluetooth socket voice option

This patch extends the current bluetooth socket option to add BT_VOICE.
This is intended to choose voice data type at runtime. It only applies to SCO
sockets.
Incoming connections shall be setup during defered setup. Outgoing connections
shall be setup before connect(). The desired setting is stored in the sco
socket info.
This patch declares needed members, modifies getsockopt() and setsockopt().
Bluetooth: Use hci_connect_sco directly

hci_connect is a super function for connecting hci protocols. But the
voice_setting parameter is only needed by SCO and security requirements are not
needed for SCO channels. Thus, it makes sense to have a separate function.
Bluetooth: Use voice_setting in incoming SCO connection

When an incoming SCO connection is requested, check the selected voice_setting,
and reply appropriately. Mode should have been negotiated previously. For
example, in case of HFP, the codec is negotiated using AT commands on the RFCOMM
channel. This patch only changes replies for socket with defered setup enabled.
Bluetooth: Parameters for outgoing SCO connections

In order to establish a transparent SCO connection, the correct settings must
be specified in the Setup Synchronous Connection request. For that,
voice_setting is added to ACL connection flags to set up the desired
parameters. If this value is zero, a legacy SCO connection will be requested.
This patch uses T2 settings.
Bluetooth: Fallback transparent SCO from T2 to T1

When initiating a transparent eSCO connection, make use of T2 settings at
first try. T2 is the recommended settings from HFP 1.6 WideBand Speech. Upon
connection failure, try T1 settings.
T2 failure is detected if Synchronous Connection Complete event fails with
error 0x0d. This error code has been found experimentally by sending a T2
request to a T1 only SCO listener. It means "Connection Rejected due to
Limited resource".
To know which of T2 or T1 should be used, conn->fallback is used.  Bluez only
attempt to reconnect twice. In the future, we will need more than 2 fallback
possibilities. Thus, test conn->fallback as an alternative measure. We want to
fallback only if conn->fallback is positive. Calling hci_setup_sync with
conn->fallback == 0 is an initial connection attempt.
Bluetooth: Add support for fallback between S3, S3, S1 settings

In case CVSD codec is requested, try to establish an eSCO connection using S3
settings. If it fails, fallback to S2 settings, then to S1 settings.
See HFP specifications for detailed description of Sx settings.

UNTESTED!!!
Bluetooth: Module parameter to force alternate setting

In USB driver, we want to test all possible alternate settings.  This is the
reason why we add this parameter to force usage of a specific alternate
setting. The alternate settings are hardcoded in Bluetooth Core Specification.
The spec defines an alternate setting 0, but we don't support this one.
In this case the value 0 is the default and means : let the driver decide
alternate setting.