Title entries from previous file were lost (and memory leaked)

Required for BD+ when bus encryption is used.

There seems to be a slight change in S-expressions (fortunately
backward compatible). There is also additional flag needed in rather
strange place (data section instead of key section), most probably a
bug in gcrypt.

Decrypting a 350MB file with gcrypt 1.5 takes around 4 seconds on Core
Quad Q9450 2.66GHz while with gcrypt 1.6 around 2.8s (the processor
does not support AES-NI).

If this is still needed, it should be implemented as run-time option (environment variable ?).

Due to the fact that AACS bus encryption was only hinted by early AACS
specification there seems to be some misconceptions.

First, what bus encryption is _not_:
- it does not encrypt all communication between drive and host
- it does not encrypt VID retrieval
- it does not use bus key (this is only poor wording in the
  specification)

Second, what is required for bus encryption to be activated:
- a bus encryption capable drive, drive certificate will have 0x01 as
  a second byte
- a bus encryption capable disc, content certificate (located in
  AACS/Content000.cer) will have 0x80 as a second byte
- a bus encryption capable host, host certificate will have 0x01 as a
  second byte

There are various combinations of all of those flags, so let's provide
a short summary:
- if drive is not bus encryption capable, then bus encryption will not
  be used, other flags are not relevant and normal AACS procedure will
  work as usual
- if drive is bus encryption capable but disc is not bus encryption
  enabled then bus encryption will not be used; however, drive will
  only allow hosts with bus encryption capable certificates, without
  one normal VID retrieval will fail, but getting VID from other
  source will make the disc playable
- if drive is bus encryption capable and disc is bus encryption
  enabled then bus encryption will be used, only hosts with bus
  encryption capable certificates can read such discs; getting VID
  from other source is not enought to read such disc as one must also
  have Read Data Key to decrypt bus encryption which is drive specific
While most of the current drives are supposed to be bus encryption
capable, most of the discs currently are not and it is quite hard to
come across one. Obviously this might change in the future.

So what is encrypted by bus encryption? Excatly the same data that is
encrypted by normal AACS, this means .m2ts files located in
BDMV/STREAM directory. Only this and nothing else. Bus encryption is
applied on the fly by the drive. Since the disc is already AACS
encrypted the host must first decrypt bus encryption and then perform
normal AACS decryption. So what is the difference? Bus encryption uses
encryption key that is drive specific, this means that the same disc
read on another drive model will produce differently encrypted
data. Without bus encryption, files simply copied from disc can be
decrypted if one gets proper VID. With bus encryption, such copy is
useless, unless proper decryption key is retrieved from the exact same
model of the drive. I am not sure if the encryption key is specific to
the drive model or every drive unit will have a different one.

This and several previous commits implement everything that is needed
to support bus encryption:
- determining if bus encryption is enabled from certificates
- retrieval of read data key that is used to encrypt data
- proper decryption (bus encryption works on sector boundary) before
  main AACS decryption

Code was tested with mplayer on LG BH16NS40 with "The Alien Anthology
Archives" disc from Alien Anthology (it is the only bus encryption
enabled disc out of 6 in the anthology).