Split tests into unit tests and integration tests.

There are many ways to do this, but in my mind the criteria of deciding whether something is a unit test or an integration test involves:

* How many objects is the test exercising? If it's only one, it's a unit test. More? Integration test.
* Is the test using any dependencies that have latency or the potential to be unreliable like a database or network calls? If so, it's an integration test.
* Does the test take longer than a second to run? If so, it's an integration test.
Add VCR for recording web requests and responses during integration tests

This improves reliability, reproducibility, isolation, and speed of the tests. The cassettes can be rerecorded at any time if they get out of sync with the Clever service.
Factor out setting of the api_key from each of the list tests
Make the tests read as grammatical English because I'm OCD
Make the list test idiomatic ruby

Use .each instead of for...in; don't use parentheses at the end of method calls that don't have arguments
Add some explicit assertions to list tests
Always use Clever.api_key instead of returning/passing api_key

This makes one canonical source for the api_key and simplifies the interfaces of the objects. I'm not sure what the use case would be for passing api_key around if we're only ever going to have one
Adding .rvmrc to the .gitignore
Use a Configuration object for the api_key instead of class variables

This is a common pattern for gems that need configuration. Class variables
have the tendency to do unexpected things:
http://www.oreillynet.com/ruby/blog/2007/01/nubygems_dont_use_class_variab_1.html
Move api_base into the Configuration object
Add usage instructions for configuring your API key
Merge pull request #4 from thinkthroughmath/ruby-style

Ruby style