@ashfurrow => Registration Flow

This takes someone new to Artsy to being registered and full set up. It also deals with logging in via Artsy u:p and updating the user to be registered and then presents you paddle + pin.

Attached to it is an experiemental version of web based bidding. There's complications around access tokens when using pin + number which basically makes it more effort than it's worth now. So I'll be switching it out in the next PR with the original native version and just going with that. Think I've got enough time to make all of it's required states.

*Note:* @1aurabrown this will not compile on yours anymore because you'll need to add some more CocoaPods keys. Run these

```
bundle exec pod keys set CardflightMerchantAccountStagingToken XXXX
bundle exec pod keys set CardflightMerchantAccountToken YYYY
```
So I don't expect that `self` will become `nil` in the duration of these signals, but if it does, I'm curious what'd happen. The docs for `then:` say that it shouldn't return `nil`, but looking at the code, it seems like that'd be OK. The return value of the block is eventually used to subscribe another subscriber:

	return [RACSignal createSignal:^(id<RACSubscriber> subscriber) {
		return [block() subscribe:subscriber];
	}];

So if the block returns nil, then `createSignal:` returns `nil`, and we have a signal that never completes. Not the worst thing in the world – worst case is I think it'd cause a memory leak. 

I think we have two options: either we can do the `?? RACSignal.empty()` every time (sucky) or we could just not `[weak self]`. I think that'd actually be OK, since the signals will complete, so the blocks aren't capturing a reference cycle. The only concern would be the model outliving the view controller that owns it. What do you think, Orta?