[osx] added: show endianness for kAudioFormat60958AC3

As per Core Audio data types reference, endianness is defined for
kAudioFormat60958AC3 format. Show it in log similarly to PCM
formats.
added: 16-bit buffer byteswap function in EndianSwap
[AE] added: perform byteswap in raw mode if sink requires it

The sink may need raw audio data either in S16_LE or S16_BE format.

Currently the code assumes that the sink takes S16_NE. However, this may
not be the case, and especially on big-endian systems the sink may need
S16_LE instead (if the audio hardware takes that instead of S16_BE).

Therefore, perform a late byteswap if needed.

It would be preferred to take this into account in the IEC-61937 packer
already, so that we wouldn't consume CPU power byteswapping padding
(which there can be a lot of) or byteswap twice. However, the IEC-61937
packer can't currently get that information from the engine/sink.
[AE] fixed: allow ALSA passthrough with non-native data format

The ALSA sink currently only tries SND_PCM_FORMAT_S16 for passthrough.
However, the non-native endianness format is not tried. The most common
case when this is needed is big-endian systems that commonly have an
ALSA device that still takes in S16_LE.

Fix that by trying both formats for passthrough if SND_PCM_FORMAT_S16
fails.
[AE] removed: incorrect comment in AEConvert

A comment says that the output is always machine byte endian, but that
doesn't seem to be the case since there are specific functions for both
endian formats.

Remove the comment.
[AE] fixed: passthrough of LE DTS, pre-padded DTS, invalid DTS

AEPackIEC61937 currently doesn't take into account that LE DTS needs to
be byteswapped to BE format (in addition to any other byteswaps) before
being transmitted to the receiver, as only the BE format is standard and
supported by all receivers. Code comment says that the "DTS spec shows
it suppors both BE and LE", but in reality there is no provision for LE
in the DTS specification.

Additionally, AEPackIEC61937 doesn't properly handle DTS streams that
are pre-padded for S/PDIF transmission. Such streams fit exactly into
the output S/PDIF stream and no padding or IEC61937 wrapping is needed
(there is not enough space for those, either).

Also, frame size is not validated properly. Valid DTS frame sizes
in the range [ BurstPeriod-BurstHeader+1 , BurstPeriod-1 ] cannot be
packed into IEC 61937 as there is no space for the burst header.
Currently the code crashes with such inputs.

Fix all three issues by adding code handling them.
[osx] fixed: incorrect mFormatFlags set for S16LE

CCoreAudioUnit::GetFormatDesc() currently sets
kAudioFormatFlagsNativeEndian for AE_FMT_S16LE.

However, S16LE is always little-endian, not native-endian, so that flag
shouldn't be set.

This incorrect value presumably didn't cause widespread issues because
on little-endian systems S16LE is also native-endian, so the code did
nothing (as kAudioFormatFlagsNativeEndian is zero), and on big-endian
systems we normally output S16BE instead of S16LE, so the codepath was
not hit.
rewritten: ALSA device enumeration and selection code

The current ALSA device enumeration code steps through all the hardware
ALSA cards and devices while trying to guess the symbolic "hdmi" and
"iec958" names that will be used with ALSA. It misses any virtual
devices, such as "pulse" or "default". In addition, it didn't have any
handling for "surroundXX", which is needed on many cards to get
multi-channel analog output. Also, it didn't find "iec958" devices that
have no separate hardware device from the analog device, like on USB
sound cards.

Solve those issues by rewriting the ALSA device handling code to use the
ALSA device name hints to determine which devices should be used. This
is the same method "aplay -L" uses.

The code will automatically use the correct front/surround40/surround51/
surround71 device depending on the amount of channels requested. This is
achieved with a magic "@" in the beginning of the device string, which
will be replaced with the wanted base device name ("front",
"surround51", etc.). In addition, the "sysdefault" and "default"
dmix-enabled (allowing shared usage) outputs will be automatically used
when available, for stereo streams that have the same sample rate as the
ALSA dmix mixer has (normally 48000Hz).

The enumeration code will now add a preferred "Default" device, which is
the ALSA default device. This allows XBMC to follow the system-wide
configuration, so that when the user e.g. modifies /etc/asound.conf or
changes environment variables ($ALSA_CARD etc.), XBMC will follow those.
The device name of the "Default" device will be either "default" or "@",
depending on if the default device needs "surroundXX" mangling for
multichannel support (normal analog devices need it, but if the ALSA
default is e.g. the pulseaudio sound server, it is not needed nor
wanted).

Also, additional differentation (device number and/or card id) is now
added to the device names when identical names were found by
enumeration.

Additionally, the AES parameters are now set even when not using
passthrough for S/PDIF and HDMI devices as specified by IEC 60958.
The code will fallback to not setting the parameters since it may
sometimes fail if e.g. using a custom device that does not accept them.

The behavior of setting parameters (channel count, sample rate) is not
altered.
added: log wrapper for ALSA errors
changed, prefer gcc atomic intrinsics when present
cosmetic clean up
[xrandr] - fix compilation with 10.04
Merge pull request #1123 from davilla/use-intrinsic-atomics

Use intrinsic atomics
changed use also intrinsic for cas
fixed: double mapping in Lircmap.xml (thanks s7mx1)
[FreeBSD] use intrinsic atomics

works with gcc and clang found on FreeBSD base system
videodb: fix UNIQUE INDEX on tag.strTag for MySQL
fix library/video/movies/tags.xml
set the content of the tags list to "tags" instead of "movies"
Merge pull request #1142 from huceke/use-intrinsic-atomics

changed use also intrinsic for cas