Merge pull request #9 from olibob/api_complete

Api complete, designed in better way
Specify dependencies correctly.
Make configuration a providable object.

Allows different configurations for different executions in the same
codebase.
Update to conversion API.

- Mostly style changes (spaces instead of tabs), new_process instead of
  newProcess.
- Changed how new_process works so that it really does create a new
  process when it's called.
  - This isn't ideal, but also suggests a larger API change than may
    have originally been planned (I'll put that under a separate PR to
    the pandurang90 repo).
Update the README for the changes.
Make configuration a little more fluent.

- Make it easier to use different configurations.
- Add documentation to configuration and client connection wrapper
  classes (the latter is hidden, as they are internal classes only).
Fluent API reorganization of Cloudconvert.

What's done:
- This builds on the work by @olibob and extended by me, but takes it in
  a different direction.
- I've added extensive RDoc documentation to the classes and added a bit
  more ceremony to the gemspec and other documentation.
- It works, at least as far as I've tested (using uploads). The best
  example right now is in bin/cloudconvert. Ideally, this command-line
  tool would be able to specify anything that can be specified, but I
  haven't done this.
- This looks like a substantial rewrite, but it isn't really. I have
  mostly refined interfaces that @olibob and @pandurang90 provided.
  The main functionality that I wrote here are the process payload
  builder classes.
- I've made it so that configuration intuits as much as is possible.
- The Process class is now pathologically incapable of being started
  more than once. This exactly mirrors the behaviour required by
  CloudConvert. There is no need to call #new_process anymore; the new
  process ID is created automatically when Process#run or Process#start
  is called.

What's not done:
- There's still no tests.
- The README has not been updated with current examples.

Thoughts and Notes:
- Even though in my contribution documents I always tell people never to
  touch the version, I've touched the version.
- I generally follow a modified version of semver in a couple of ways.
  To me, the 0.x.y version series is fairly free to change the API as
  long as the minor version clearly indicates that there are possibly
  breaking changes.
- If this were my project and gem, I'd *probably* make this version a
  0.8 or 0.9 release with a fast-track toward a 1.0 release once the
  tests are in place.
- I'd also do release management with Hoe…but I've got a few gems out
  there that I release pretty regularly and have built my workflow
  around Hoe. I might consider using
  https://github.com/postmodern/rubygems-tasks these days if I were
  starting fresh. Maybe.

Sorry about the size of the changes here.