Detecting duplicate dependencies in specification doesn't distinguish between runtime and development dependencies

https://github.com/rubygems/rubygems/commit/03dbac93a3396a80db258d9bc63500333c25bd2f (released in 2.2.0) introduced a feature where rubygems would error if a dependency was specified twice in a gem specification.

I think it might be too strict however as it doesn't seem to distinguish between runtime dependencies and development dependencies.  It's not hard to come up with a scenario where a runtime dependency could be less strict than a development dependency and so you would want to specify the dependency twice.

For example: I work at a company that publishes a gem that provides some new matchers for rspec.  The matchers work in any version of rspec, but our own specs for the gem are written against rspec 3.  I'd expect to be able to specify that dependency graph as follows:

```ruby
Gem::Specification.new do |gem|
  gem.add_runtime_dependency('rspec')
  gem.add_development_dependency('rspec', '>= 3.0')
end
```

However, issuing ``gem build`` errors out with:

```
WARNING:  open-ended dependency on rspec (>= 0) is not recommended
  if rspec is semantically versioned, use:
    add_runtime_dependency 'rspec', '~> 0'
WARNING:  See http://guides.rubygems.org/specification-reference/ for help
ERROR:  While executing gem ... (Gem::InvalidSpecificationException)
    duplicate dependency on rspec (>= 3.0, development), (>= 0) use:
    add_runtime_dependency 'rspec', '>= 3.0', '>= 0'
```

That it suggests the solution is to replace my ``add_runtime_dependency`` and ``add_development_dependency`` lines with a single ``add_runtime_dependency`` definitely seems wrong as that would end up making the gem only available to rspec 3 users when it works happily on rspec 1 or 2.

I think it would make sense to collect the ``seen`` dependencies depending on the ``dep.type`` and only error out if we specify a runtime dependency twice, or a development dependency twice, but allow us to specify a dependency with different constraints for runtime and development.

I'm happy to take a shot at working this up as a PR if you think it sounds like a good idea.