This commit adds the very beginnings of BSIP 40/Custom Active
Authorities, including a working implementation of the core logic which
evaluates whether an operation complies with a list of restrictions.

Notably, I made an overhaul to the fee logic here. The old logic was
incredibly complex and had weird multiply-by-zero edge cases to get a
free fee... I dropped the whole thing and replaced it with a simple
price per byte, which should have a fairly similar effect without
segfaulting anyone's brain.

Implementation passes cursory tests.

Restrictions now specify the field they restrict by member index rather
than member name. Although this change makes restriction objects more
opaque to human readers and increases the compile-time complexity of
restriction_predicate.cpp, using indexes is faster at runtime, smaller
when serialized, and allows renaming of members in future code updates.

This also improves the build time on all compilers

Reduce peak RAM usage during build by splitting the build up over
several different .cpp files, each of which should compile in under 3
minutes and 5GB or less RAM.

Set travis to build single-threaded and disable signed-unsigned
comparison warnings on g++. If anyone has a real solution to
signed comparisons, I'd love to hear it, but until then, the
warnings are actually so awful that travis breaks over them.

Restriction predicates now collect data specifying exactly which
restriction(s) rejected the operation.

Part 2 will be rendering this data to a user-readable message.

The multi-stage build makes builds more reliable by building only
the protocol in the first stage, which reliably passes in time,
caching those binaries, and then building the rest and running
tests in the second stage, which uses the cache to complete in
time as well.

Add the wrapping to report errors back to the user... such as it is
Eventually, I'd like to add more logic towards generating a user-
comprehensible error message, but this will suffice for now.

This implementation provides enough information to construct, in
conjunction with the restriction list and operation in question, a
message describing the error in detail to the user... but actually
assembling that message is, for now, regarded as a UI problem.

Remove the committee parameter used to determine whether an operation
type had been hardforked in yet, and replace it with hardfork_visitor

Many thanks to @jmjatlanta! :)

Old boost apparently didn't have this, and it's worth stealing

Added a new function type to restrict the value of a static_variant field
on the operations. This also spun off into reworking the error handling
to more adequately report the reason for predicate rejections.

Ordering the rejection path from the outermost restriction to the
innermost (point of rejection) is more intuitive, so reverse the order
of the path when returning the predicate result.

…g logical OR branches

Just some typo fixes

BSIP 40: Unit tests

Add specializations to allow `in` and `not_in` restrictions to operate
on all values in a container field