der: better names for `Decodable`/`DecodeValue`/`Encodable`/`EncodeValue`

[tarcieri]

The four main traits that comprise the decoding/encoding API have somewhat inconsistent names. To break them down along with their function:

Document / TLV decoding/encoding traits:

These traits also represent the main end user-facing API for those who wish to decode/encode DER documents:

• Decodable
• Encodable

Value decoding/encoding traits:

These traits are primarily used by ASN.1 format implementers, and are emitted by der_derive when using the Choice or Sequence macros:

• DecodeValue
• EncodeValue

Unlike Decodable/Encodable, these traits are specifically for parsing the "value" portion of a tag-length-value production, and they receive the TLV Header (tag/value) as an argument.

Having a separate trait for value decoding/encoding is important for implementing IMPLICIT context-specific productions, which may have arbitrary context-specific tags.

Problems

At the very least, the "-able" endings on Decodable and Encodable are inconsistent with the non-"able" endings used by DecodeValue/EncodeValue.

[tarcieri]

One option is to just drop the "-able" endings, and changing the former to Decode and Encode.

Another might be to try to make those traits more specific, like DecodeTlv and EncodeTlv to indicate these traits are used for tag-length-value encoded data.

While DecodeTlv and DecodeValue are nice from the perspective of the implementer of a given ASN.1 schema, I think they might be less so for someone who just wants to use a format decoder/encoder, where Decodable/Encodable are the primary user-facing API and *Tlv in that context could be confusing jargon.

[tarcieri]

Proposed changes implemented in #523