Accept `to` parameter; Refactor profile parsing

On @jparkrr's suggestion, we're going to using `to` and `from` to denote the
profile you're posting an item to and who you're posting it as. Since they'll
have the same format, `parseProfileList` now encapsulates that logic.

The `services` parameter should be considered deprecated.

This happens to clear up some noise we were probably getting in statsd, where we
used to pass things like `singlytesting@tumblr` when we meant just `tumblr`.
I can imaging us wanting to note whether there was a target profile or not to
measure usage, but not in this commit.
Pass `to` to service posting modules

Just cleanliness and consistency; We're going to need `from` in order to pick
the right access token / whathaveyou to post as.
Accept, validate and pass through a `from` param

We require that if you include a pid in `from`, it must be of the form
`id@service` - no sense trying to post as just `facebook`. You may also only
include 1 pid per service, else we'll be similarly confused.
Use FB Page tokens while posting

If the declared `from` is not the user ID (or empty), we load the user's pages
and scan them for a matching ID. If found, its access token is used. Otherwise,
we let you know you don't have a token for it and what you might be able to do.
Accept multiple `to` or `from` parameters

If your request has multiple `to` parameters, eg

    POST /types/statuses?to=foo&to=bar

the parameter comes in as

    ['foo', 'bar']

which wouldn't allow `list.match` in `parseProfileList`, which was expecting a
string.

This just makes sure it's a string before it makes sure it's an array, which is
sort of sad but will be most robust to people including multiple,
comma-separated `to` parameters.
Accept service params that are already JSON

In the first implementation, I assumed that `*_params` would be a string, but
sometimes (like if you use `facebook_params[foo]=bar` syntax), Express can parse
it into an object. This accepts that.

We were also making the request anyway (potentially without the service
parameters), but you'd see an error in the response that we couldn't parse it.
Now only see that error if we definitely didn't try a request.
Ensure `from` data is always present while posting

The user may not pass a `from` parameter (though they must pass `to`), but for
consistenty, it will always be available in the service's posting module. Like
`to`, it will always have a `service`, but the `profile` may be undefined.
Allow posting to targets that are not the actor

This theoretically allows any of the four user/page interactions:
* User posts to own feed
* User posts to page's feed
* Page posts to own feed
* Page posts to user's feed

In practice:
* Pages don't appear able to post to a user's feed
* Posts from average users seem to have strange rules for appearing
* Page admins can only appear as the page, not themselves
  - This was supposed to be fixed, but Facebook removed it silently from their
    roadmap.
  - http://stackoverflow.com/questions/12186002/facebook-api-posting-as-self-on-page-i-admin
  - https://developers.facebook.com/blog/post/2012/08/08/platform-updates--operation-developer-love/
    (Actor name will always match the access token)
add collaborator array for apps and check it, plus convenience wrapper
convert all app api fetches to the new validated one
Merge pull request #636 from Singly/post-to-fb-pages

Posting to facebook pages
typo fix
Merge branch 'master' of github.com:Singly/hallway into app-collab
remove old crumb
shorter tokens ftw
swap out the scary equals with a period
tweak for better error code
Initial commit that adds /authenticate path and adjusts finishAuth logic for new behaviour
Add support for using access_key to bind a new account to an old one
Fix underscored variables, per review.