(resubmitting) Discretionary data objects nesting fix

Resubmitting this so my changes are on a clean branch. [More detail here](https://github.com/Yubico/ykneo-openpgp/pull/19#issuecomment-63092162).

Per the OpenPGP card specification (4.3.1 "DOs for GET DATA") and ISO 7816-4 (5.4.4.3 "Independent tag allocation schemes"), discretionary data objects in application related data must be nested within the 0x73 discretionary data objects tag. The current implementation almost does this; unfortunately, the discretionary data objects tag has a hard-coded length of 0, so when the objects themselves follow they are not nested: 

    Output of GET DATA 6E, vanilla Yubikey NEO
    6E 81DD                                                    # Application Related Data, length 221
     ├─4F   10 D2 76 00 01 24 01 02 00 00 06 03 01 51 21 00 00 # Application AID
     ├─5F52 0F 00 73 00 00 80 00 00 00 00 00 00 00 00 00 00    # Historical Bytes
     ├─73   00                                                 # Discretionary Data Objects of length 0
     ├─C0   0A F0 00 00 FF 04 C0 00 FF 00 FF                   # Extended capabilities
     ├─C1   06 01 08 00 00 11 03                               # Algorithm Attributes
     ├─C2   06 01 08 00 00 11 03                               # Algorithm Attributes
     ├─C3   06 01 08 00 00 11 03                               # Algorithm Attributes
     ├─C4   07 01 7F 7F 7F 03 03 03                            # PW Status Bytes
     ├─C5   3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 # Fingerprints
     ├─C6   3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 # CA Fingerprints
     └─CD   0C 00 00 00 00 00 00 00 00 00 00 00 00             # Key generation timestamps

This patch correctly sets the length of the discretionary data objects tag, bringing the behavior of the application in line with the spec: 

    Output of GET DATA 6E, with patch applied
    6E 81DE                                                    # Application Related Data, length 222
     ├─4F   10 D2 76 00 01 24 01 02 00 00 00 00 00 00 01 00 00 # Application AID
     ├─5F52 0F 00 73 00 00 80 00 00 00 00 00 00 00 00 00 00    # Historical Bytes
     └─73 81B7                                                 # Discretionary Data Objects of length 183
        ├─C0 0A F0 00 00 FF 04 C0 00 FF 00 FF                  # Extended capabilities
        ├─C1 06 01 08 00 00 11 03                              # Algorithm Attributes
        ├─C2 06 01 08 00 00 11 03                              # Algorithm Attributes
        ├─C3 06 01 08 00 00 11 03                              # Algorithm Attributes
        ├─C4 07 00 7F 7F 7F 03 03 03                           # PW Status Bytes
        ├─C5 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 # Fingerprints
        ├─C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 # CA Fingerprints
        └─CD 0C 00 00 00 00 00 00 00 00 00 00 00 00            # Key generation timestamps

While the gnupg desktop application seems to accept this DO whether the length is set correctly or not, the "official" cards available from Kernel Concepts do set the length properly, and this change brings the applet in line with the relevant specifications.