Enhanced ECC handling

Allow the use of a "spki" SubjectPublicKeyInfo as ECPublicKeyChoice

See PKCS15 1.1 Section 6.4.3 and RFC 5280.

This has some advantages as the algorithm parameters are saved in the spki.
Unlike RSA that has no algorithm parameters, EC does, and is usually the OID of
a named curve.

OpenSC has not handled algorithm parameters well, and this code addresses parts
of that. The same structure,  sc_pkcs15_ec_parameters is used in both the
sc_algorithm_id->params and the sc_pkcs15_pubkey_ec->params The sc_ec_params in
opensc.h has been removed.

asn1_encode_ec_parameters(), asn1_decode_ec_parameters() and
asn1_free_ec_parameters() has been update.

sc_pkcs15_decode_pubkey_ec has been expanded to check for a spki, and if so it
will call sc_pkcs15_pubkey_from_spki and then extract selected fields.

A new routine: sc_pkcs15_encode_pubkey_spki (based on the code from
pkcs15-tool.c) to create a spki from a sc_pkcs15_pubkey This works on any pubkey,
as it using the existing sc_pkcs15_encode_pubkey routines.

pkcs15-tool.c was modified to use the sc_pkcs15_encode_pubkey_spki. This means
EC pubkey now have the parameters.

the windows minidriver when used with the PIV card should now see the public keys.

NOTE:
This modification also hits pkcs15-piv.c, pkcs15-myeid.c, and pkcs15-sc-hsm.c

TODO:

The ecpointQ is stored as an octet string, as that is what PKCS#11 requires. This
gets confusing as to it should be stores as just the bits, and not as asn1. the
sc_pkcs15_encode_pubkey_ec ends up doing a decode and the
sc_pkcs15_decode_pubkey_ec does an encode.

PKCS15 allows DSA, DH, DSA, and KEA to be stored as an spki. I would assume
GOST3410 could be stored that way too?

If the sc_pkcs15_pubkey_[encode|decode}* routines were re-worked, the algorithm
parameters could be accessed and updated for all encryption types. GOST3410 would
be most affected.

The pkcs15-piv.c handling of public keys could be improved especially when no cert
is on the card, i.e. when generating a certificate request.