Adding a test to verify this works, and that this doesn't break other NSNumber instances
that store 0 or 1.

It takes a single parameter, an `STPConnectAccountParams` object. This has an optional
BOOL and an optional STPLegalEntityParams object (one of fields must be provided).

Still TODO: adding `description` implementations in STPLegalEntityParams.m, and
testing!

This currently fails, because `legal_entity` is actually required all the time, contrary
to what I thought.

These are pretty basic, but then so are the implementations of the classes.

I wanted to add custom Asserts (like https://www.objc.io/issues/15-testing/xctest/#custom-assert-macros)
for these *very* repetitive tests (which already exist 4x times), but I think this is
okay-ish.

Last night I had moved the public headers into the right directory to fix a different
failure, and rebased that into 3f2bc39.

Now that bg-stripe's reviewed this PR, not going to force-push anymore.

…galEntity:`

…t:completion:`

…ormance.

Faux Pas (correctly) points out adding un-prefixed methods to a Foundation class via
a category is dangerous. Probably a better thing to do is either prefix all of these
methods in the protocol, or add custom support for `NSDateComponents` in
`+[STPFormEncoder formEncodableValueForObject:]`.

For now, I think this is safe enough.