Bug fix Gem::Version.create

Do not assume an object is of type Gem::Version just because it responds to
:version
Fix test for Gem::Version.create change

Test changes due to intentional code behavior change.

The comment "FIX: For "legacy reasons," any object that responds to +version+ is
returned unchanged. I'm not certain why." is no longer applicable as I removed
that functionality in my previous patch. I was not certain why either :)

Instead objects of type Gem::Version are simply not cast by Gem::Version.create.
Compare self, not self.class to input

Fix bug in my patch cought by the test. Per drbrain.
Since this is a class method self.class is Class, which is unhelpful.
Replace confusing quotes in exception with inspect
Install files starting with '.' (Fixes #680)

The '*' pattern doesn't match files starting with '.' unless you
use File::FNM_DOTMATCH.  Some gems depend on files starting with
'.' being installed.  Excluding files starting with '.' was not
the intention of the author that added the fnmatch code.
Add pretty_print for InstallerSet

Add always_install to #inspect as it was missing
Separate lines for readability
Add missing "then"
Use string platform for resolver specifications

When looking up specifications the resolver sets expect string
platforms.

For a local gem the parsed platform was available and used for looking
up the specification.  The specification was stored with a string
platform which meant the gem was not available (causing an exception).

Now the IndexSpecification always uses the string version of the
platform to prevent this bug.

Fixes #664
Add functional test for #664

I think the test for #664 is insufficient to prevent recurrence of the
bug.  This test uses the same operations as the resolver to help ensure
a regression does not occur.
Merge pull request #681 from jeremyevans/master

Install files starting with '.' (Fixes #680)
Add #680 and #681 to History
Ignore default gems when building indexes

When default gems were added they managed to slip their way into the
index generation code as they were not explicitly included.  This meant
uninstallable gems where included in the index.

Now the default gems are filtered out of the index.

Fixes #661
Remove trailing whitespace
Merge pull request #674 from jkanywhere/gem-version-create-bug-fix

Bug fix Gem::Version.create
Update History with 2.1.8 release
Added #674 to History
Reduce sorting in SpecFetcher#tuples_for

When fetching tuples for a source the #tuples_for method would first
look in the cache of types and sources, then sort the result.  This
meant that the sort would be performed each time the tuples were
fetched which could take some time.

Now the tuples are sorted before being placed in the cache so subsequent
fetches do not need to repeat the expensive sorting.

This significantly speeds up the outdated command, probably the update
command too.

See #657
Rebrand #657 as a bug
Change extensions dir order.

There are several reasons to do that:

- It will preserve the current state, i.e. there is folder with
  full_name and under that folder, there is the extension, without any
  addition clutter.

- If we consider other alternative Ruby implementations such as Rubinius,
  it speaks in favor of this proposal as well. It means I could go into
  Rubinius folder and rebuild every gem extension I'll found. The opposite
  way, such as go into each gem folder is less favourable (although
  possible). Additionally, if I remove Rubinius, I can simple delete whole
  directory branch instead of iterating through the folders.

- It will ease packaging. I.e. the RubyGems package owns the platform
  specific folders, the gem package owns just its own sub-directory with
  its content. In current state, the platform specific of the gem would
  need to share ownership of the gem directory, which is repetitive.

- It follows the principle of mutliarch Linux distributions. E.g. there
  is arch specific folder and in this folder resided library, not the
  opposite.