Match or exceed v1 performance

[jhollinger]

After V1's recent perf improvements, V2's perf was no longer looking so good. These changes make V2 competitive again:

• Stopped using the extension API for conditionals and default values. While cool, there was an optimization ceiling.
• Fewer method calls and allocations during serialization (particularly when extensions aren't used).
• Removed & simplified some extraneous features not present in V1. Allowed removal of lots of tests.

Perf varies with the number of fields, objects, and collections. It can also vary between the top-level serialization being a collection or object (collections are faster b/c some overhead is shared across loops). Use of extensions also caries some overhead (none were used in the measurements below).

# Collection results (20 fields, 5 objects, 2 collections)
1,000 widgets 100x: V2 change: -59.72%
500 widgets 100x: V2 change: -60.23%
250 widgets 100x: V2 change: -60.50%
100 widgets 100x: V2 change: -61.48%
25 widgets 100x: V2 change: -62.42%
5 widgets 100x:  V2 change: -60.14%
1 widgets 100x:  V2 change: -54.12%

# Object results (20 fields, 5 objects, 2 collections)
1,000 widgets 100x: V2 change: -32.68%
500 widgets 100x: V2 change: -33.49%
250 widgets 100x: V2 change: -32.39%
100 widgets 100x: V2 change: -35.35%
25 widgets 100x: V2 change: -36.85%
5 widgets 100x:  V2 change: -54.16%
1 widgets 100x:  V2 change: -52.25%

One thing we lost here is the ability to have extensions that are initialized per-render. I think it's possible to add again, but it will be more complicated, so IMHO we should wait until someone needs it.

Some other changes include:

• Allow the fields DSL method to receive options and a block
• Rename the field from option to source (reads better)
• Allow around_blueprint_init to modify blueprint options and field details (previously it could only change field order or filter out fields)
• Documentation branch: jh/release-2.0-docs