Remove debug line
Create posting endpoint with basic tests

visionmedia/supertest@master does pretty much what we want for basic API
testing. It makes it easy to pass query/post parameters, and lets us go through
the real Express stack instead of mocking everything.

Set up lines like `helper.configurate()` don't appear necessary for now, so I'm
leaving them out until they are.
Lint authManager

- ===
- Semicolons
- Defined functions before use
Lint oauth2-provider

- ===
- Extra comma
- Prefer dot notation
- Invoke constructors with `()`
Include an access_token in tests

This doesn't auth all the way through, but it's progress.
Pend tests for now

The OAuth provider setup is hard to fake our way through, and there's a lot of
account and profile data underneath to set up. Postponing for now for sake of a
proof of concept.
Lint syncManager

- ===
Load synclets during syncManager require

Since it's just reading from the file system, this can happen during the initial
read of `syncManager` and make it easier for others to require the library
without having to run initialization themselves.
Basic Posting pathways

Upon load, we try to load each service's `posting` module. When a request is
made, we pass off the incoming data to any that exist. The response is a JSON
object of the form

    https://api.singly.com/types/:type?access_token=TOKEN&services=a,b,c

```
{
  "service": {
    // response JSON
  },
  "service": {
    "error": "What's up"
  }
}
```

If you forget to include any services to post, you get back a top-level error.
Post out to Twitter

Our canonical parameter will be `body`, and for WordPress or Tumblr, also
`title`.

If Twitter responds with an error, we parse it and hoist it into
`response.twitter.error` so the developer can handle things consistently. We may
want to also return the original error, but I'll leave that until there's a use
case.

Some errors don't make sense or can be actively confusing, like "Client must
provide a 'status' parameter with a value.", and we'll have to handle those
intelligently for the developer. The fix for that one is coming up next.

Closes #482
Require `body` parameter when posting a status

Twitter's error message refers to a `status` parameter, which would be confusing
to developers. We can catch that to be clearer, and may as well avoid making API
calls at all.
Post statuses to Facebook

Well that was easy.

Closes #480
Post statuses to Yammer

Yammer's API is a little more finicky than some. If you don't include an access
token, they just return `' '` instead of something useful, and I imagine they'll
do that in other cases as well. For now, it's just caught with a generic "Yammer
didn't return JSON.", and as we encounter more, we can figure out what to do.

Closes #495
Add HTTP POST to the LinkedIn library

LinkedIn is really finicky about what you pass its API: POST data is taken from
the request body like you'd expect, but you have to put the `format` param into
the URL or else it gets caught by their param whitelists and you get back an
XML error with a list of acceptable parameters.

Refactored the OAuth client creation since it's used in both `post` and
`genericSync`.
Post statuses to LinkedIn

Though LinkedIn's
[share api](https://developer.linkedin.com/documents/share-api) says you should
pass it a top-level `share` object, that only applies to XML. When using JSON,
they appear to wrap the whole POST body in the `share`.

As noted in the comments, success gives you back an empty HTTP 201 with a
`Location` header telling you where the share is. Their docs note that the URL
provided there isn't actually available, but it's a source of the share ID that
we can use in our own success response. We can parse the ID out if we like, but
it'll be irrelevant if we return the full share data after #498.

Closes #494