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)