Minor fix to be able import local OVA files

OVA -> cube conversion is not working for me for some reason.

The patch changes the convert_cube.rb request so that when converting
the OVA to a Cube, all the cube files remain in the same directory
(named after the cube name).

Right now (without the patch), the conversion process produces:

```sh
$ find ~/.octocloud/boxes/
/Users/rubiojr/.octocloud/boxes/
/Users/rubiojr/.octocloud/boxes//test-cube
/Users/rubiojr/.octocloud/boxes//test-cube/.md5
/Users/rubiojr/.octocloud/boxes//test-cube.vmwarevm
/Users/rubiojr/.octocloud/boxes//test-cube.vmwarevm/vmwarebox-disk1.vmdk
/Users/rubiojr/.octocloud/boxes//test-cube.vmwarevm/vmwarebox.vmx
```

So the .md5 is created in a different directory (test-cube). This
apparently breaks cube listings at least.

The code I'm using to test:

```ruby
require 'pp'
require 'fog'
require 'fog-octocloud'

octoc = Fog::Compute.new( :provider => 'octocloud' )
cube = octoc.cubes.create :name => 'test-cube',
                          :source => File.expand_path('~/tmp/tinycore-477.ova')

pp octoc.cubes
```

This raises an exception when listing the cubes after
importing/converting the OVA to a Cube:

```sh
/Users/rubiojr/tmp/fog-octocloud/lib/fog/octocloud/requests/compute/local_list_boxes.rb:12:in `initialize': No such file or directory - /Users/rubiojr/.octocloud/boxes/test-cube.vmwarevm/.md5 (Errno::ENOENT)
        from /Users/rubiojr/tmp/fog-octocloud/lib/fog/octocloud/requests/compute/local_list_boxes.rb:12:in `open'
        from /Users/rubiojr/tmp/fog-octocloud/lib/fog/octocloud/requests/compute/local_list_boxes.rb:12:in `block in local_list_boxes'
        from /Users/rubiojr/tmp/fog-octocloud/lib/fog/octocloud/requests/compute/local_list_boxes.rb:9:in `map'
        from /Users/rubiojr/tmp/fog-octocloud/lib/fog/octocloud/requests/compute/local_list_boxes.rb:9:in `local_list_boxes'
        from /Users/rubiojr/tmp/fog-octocloud/lib/fog/octocloud/models/compute/cubes.rb:14:in `all'
        from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/fog-1.14.0/lib/fog/core/collection.rb:141:in `lazy_load'
        from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/gems/1.9.1/gems/fog-1.14.0/lib/fog/core/collection.rb:22:in `pretty_print'
        from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/1.9.1/pp.rb:154:in `block in pp'
        from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/1.9.1/prettyprint.rb:217:in `block (2 levels) in group'
        from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/1.9.1/prettyprint.rb:243:in `nest'
        from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/1.9.1/prettyprint.rb:216:in `block in group'
        from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/1.9.1/prettyprint.rb:228:in `group_sub'
        from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/1.9.1/prettyprint.rb:215:in `group'
        from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/1.9.1/pp.rb:154:in `pp'
        from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/1.9.1/pp.rb:77:in `block in pp'
        from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/1.9.1/pp.rb:121:in `guard_inspect_key'
        from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/1.9.1/pp.rb:77:in `pp'
        from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/1.9.1/pp.rb:60:in `block in pp'
        from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/1.9.1/pp.rb:59:in `each'
        from /opt/boxen/rbenv/versions/1.9.3-p448/lib/ruby/1.9.1/pp.rb:59:in `pp'
        from test2.rb:18:in `<main>'
```

With the patch applied, the <cube-name>.vmwarevm directory is renamed to
<cube-name> and the .md5 is created inside of it.

I'm not really sure if this is the behaviour we should expect so any input on
this is greatly appreciated.