Implementing core fc4j 2.0 functionality

[#80392902]
So, assuming the thought process here will remain (i.e. if these few lines are uncommented) it's going to be somewhat problematic. Probably my fault for poor explanation, but in general, no application is going to consume FullContact without an ApiKey. If a consumer is gathering access tokens from other applications, it's in the wrong. Every application should be gathering access tokens from it's api key via login or another means that somewhere down the line involves it's api key. That being said, I think it's fair to say that every FullContact object should be instantiated with an apikey specifically (vs an 'auth string'), and never an access token. Then, when making requests, the client should optionally be able to specify an access token, and at that time the request should not include an api key. 

One could argue that they both can be sent, for instance cardreader looks at access token before api key if both are sent, I'm just not sure how cab or other applications handle this and really it's unnecessary because the token includes a reference to the api key.

So I imagine something along the lines of this (generically speaking):
```
FullContact fc = FullContact.withApiKey("always-an-apikey").build();

GenericRequest personRequest = fc.buildGenericRequest().path("person.json").param("email","bart@fullcontact.com").build();

GenericRequest cardreaderOrCAB = fc.buildGenericRequest().path("cardreader")....accessToken("this-users-token").build();
```

So TLDR, assuming we have access tokens from login doesn't mean we are instantiating FullContact with that token. One application can be using FullContact (one api key), and many access tokens (one+ per user).