Introduce "Capabilities" notion

[GoogleCodeExporter]

NFC device have different capabilities: some are able to do one or more of 
these features:
 - HW emulation of ISO/IEC 14443-4
 - Initiate an ISO/IEC 14443-B communication
 - Send 264 payload bytes (instead of 254 payload bytes)

It may be useful to request if one of these capabilities are supported before 
running.
examples given:
 - do not accept 255 bytes C-APDU if payload is limited to 254 (in nfc-emulate-forum-tag4);
 - request supported modulations before starting to select (in nfc-list)
 - do not start NFC-Secure communication if chip doesn't support it

If someone have ideas to complete this issue or to handle the problem, feel 
free: feedback is open :)

Original issue reported on code.google.com by romu...@libnfc.org on 13 Apr 2011 at 6:17

[GoogleCodeExporter]

 - Supported modulations/standards as Initiator (with supported baud rates)
 - Supported modulations/standards as Target (with supported baud rates)
 - Hardware assistance for special standard (ie. PN532 with ISO/IEC 14443-4A)
 - maybe polling capability (IMHO, we should implement software polling when not available internally)

Original comment by romu...@libnfc.org on 12 Jul 2011 at 7:43

[GoogleCodeExporter]

 - CRC and parity disabling capability
 - Manual-made anticol / raw bits sending capability
 - Timed functions available

Original comment by romu...@libnfc.org on 12 Jul 2011 at 7:52

[GoogleCodeExporter]

- bugs (e.g. for PN531 using InDataExchange with ISO14443-4 card “If 
parameter P3 (from C-APDU in DataOut[]) is greater than 0xFA (250 bytes), the 
C-APDU command is not sent and the PN531 returns a status byte with error 
0x07.”

Original comment by romain.t...@gmail.com on 12 Jul 2011 at 8:26