Added a test showing that chef_api_location leaks threads

Added a test showing that chef_api_location leaks threads.  This "thread
leak" becomes apparent very easily on a Windows system when a berks
install downloads 20 to 25 (or so) cookbooks from a chef server (by
which time close to 1000 threads exist in the process).  This problem
also exists on linux, but generally a process on linux can create many
more threads before a problem shows up.  This test currently fails and
will be fixed by code changes to chef_api_location.rb in a subsequent
commit.
Fixed "can't create Thread" and "failed to allocate memory" errors on Windows.

When downloading cookbooks from a chef api location, berkshelf was
sometimes blowing up with "can't create Thread" or "failed to allocate
memory" errors.  This happened especially easily on Windows systems.
The error was due to a "thread leak" in chef_api_location.rb.  This leak
becomes apparent very easily on a Windows system when a berks install
downloads 20 to 25 (or so) cookbooks from a chef server (by which time
close to 1000 threads exist in the process).  This problem also exists
on linux, but generally a process on linux can create many more threads
before a problem shows up.
In chef_api_location finalizer, call terminate! instead of terminate (async instead of sync).

When running the tests, errors were occurring in Celluloid saying
"Couldn't cleanly terminate all actors in 10 seconds!"  (The tests call
Celluloid.shutdown before each example, which terminates all Actors, and
that shutdown call was producing this message).  The cause was that the
finalizer on the ChefAPILocation class was calling terminate on the
ridley connection synchronously.
Removed blank space at end of line for code quality tests
Fixed typos in comment block