Verify Comparable Interface for Threshold Conditions

[sappenin]

Currently, the RFC mandates that Threshold sub-conditions be sorted/ordered according to their byte-values:

The SET of DER encoded sub-conditions is sorted according to the DER encoding rules for a SET, in lexicographic (big-endian) order, smallest first as defined in section 11.6 of itu.X690.2015.

Doing this properly potentially involves padding certain octets, per itu.X690.2015:

11.6 Set-of components
The encodings of the component values of a set-of value shall appear in ascending order, the encodings being compared as octet strings with the shorter components being padded at their trailing end with 0-octets.
NOTE – The padding octets are for comparison purposes only and do not appear in the encodings.

This places quite a burden on various implementations of the spec since in order to perform the comparison, under certain circumstances, all of the bytes of a Condition/Fulfillment might be compared.

First, we should validate that the Java implementation properly implements this (see ConditionBase#compareTo). Second, we should consider perhaps a different ordering in the RFC, such as possibly by cost/type, or some other cheaper, yet properly ordered, mechanism.

[sappenin]

Closing in-favor of ripple/crypto-conditions#8