ENOSYS alternatives

[jedisct1]

Following Dan's insightful comment on PR#13, we can indeed replace ENOSYS (or equivalent) with a set of more informative codes.

Reviewing the current signature code and places where ENOSYS are currently used, I can see 4 different causes:

• "Currently not implemented": this applies to functions which are documented as optional, and that haven't been implemented by a host. For example, key generation for some algorithms may be too expensive or irrelevant for a platform (e.g. IoT). They may be implemented later. Their absence differs from the causes below.
• "Unsupported / Irrelevant for that platform": an example is creating a secret key from an identifier on a platform that doesn't offer key management.
• "RNG error": secrets cannot be generated and non-deterministic signature schemes cannot be used, either because the platform doesn't have a CSPRNG or it is currently unavailable
• "Prohibited by local policy": key generation is disabled because the local policy requires this operation to be performed offline, a cipher cannot be instantiated because the local policy forbids that key size or the algorithm has been disabled.

Does that list make sense?

Any other cases we should think about?

[jedisct1]

Cases 2 is a good candidate for optional imports.

Other cases depend on function parameters, so these should probably return an error code.

If multiple related functions depend on a given optional capability, we can return either a relevant handle or one of the errors above.

[jedisct1]

PR #14 was updated for this.