Holding on to the GVL means we can't do anything in parallel.  Since
these are CPU-only operations that do not involve the ruby interpreter,
we can safely unlock the GVL when calculating hashes.

This program demonstrates the difference:

```ruby
require 'bcrypt'
require 'thread'

GUESSES = (ENV['GUESSES'] || 100).to_i
THREADS = (ENV['THREADS'] || 1).to_i

p GUESSES: GUESSES, THREADS: THREADS

password = BCrypt::Password.create 'hello world!'

queue = Queue.new
GUESSES.times { queue << "x" * 90 }
THREADS.times { queue << nil }
THREADS.times.map {
  Thread.new {
    while guess = queue.pop
      password == guess
    end
  }
}.each(&:join)
```

Without this patch:

```
[aaron@TC bcrypt-ruby (master)]$ time THREADS=4 ruby test.rb
{:GUESSES=>100, :THREADS=>4}

real	0m30.014s
user	0m29.739s
sys	0m0.153s
```

With the patch:

```
[aaron@TC bcrypt-ruby (master)]$ time THREADS=4 ruby -Ilib test.rb
{:GUESSES=>100, :THREADS=>4}

real	0m12.293s
user	0m42.382s
sys	0m0.169s
```

If you run this program with the patch, you can see Ruby use nearly 400% CPU,
as long as you have a 4 core machine.

The crypt library is almost certainly using `malloc` and not `xmalloc`.
We should use `free` instead of `xfree` to ensure the malloc / free
calls are correctly balanced.