Remove APDU-batching and define T=0 protocol handling

[martinpaljak]

The BLE interface is comparable to the NFC interface, in high level. By definition, APDU-chat is a command-response pair protocol. In Java terms, the smallest interface to use is byte[] transmit(byte[]), like the relevant Android interface.

Responses to APDU commands, from the secure element, must be checked, depending on context, at earliest point and the only place where this can happen is the caller (not the SE element itself or the BLE server implementation, which have no knowledge of the context of those command-response pairs).

If the BLE interface is implemented against an always connected secure element via T=0, additional commands are to be sent to the secure element when the returned SW is 61XX or 6CXX. This must be documented for APDU handling.

Removing the additional APDU nesting allows to trim the protocol by a few bytes to speed it up slightly.

[martinpaljak]

Similar to #8 but removes the "first layer".

[martinpaljak]

Related to fidesmo/apdu-over-ble-android#7