Leverage metadata to populate gems urls

Lets have keys for the common urls we associate with ruby gem projects per #718

The README has defined `issue_tracker` as an example metadata entry. So I went with that.
There were a few examples in the wild with the source code defined as `source_url` - and other seemed to like this as well. It is unfortunate that these two are not consistent.

The others (`wiki_url`, `documentation_url`, and `mailing_list_url`) were my best stab. Don't think anyone really had much of an opinion. We can remove from this PR if you want. I added it since those fields are available in `rubygems.org`.

Thanks

/cc @qrush @fwolfst

---

**UPDATE:**

Wanted to include my rationale.

Most people don't know you can add urls in rubygems.org.
Personally, I had thought the other gem authors had fancier rubygems pages because they knew more about the gemspec.
So I looked at their gemspec, and even rubygems source just to find out there was a rubygems web UI. Who knew?

Since there are questions on the mailing list and gh issues, I realized I'm not the only one confused by this. Also, all of the data in rubygems is from the gemspec save these 4 fields. Seems like a good candidate for moving these fields into the gemspec as well.
I wasn't really thinking in terms of duplication, but in terms of extensibility.  

```ruby
  update_attributes! {
    :home => spec.homepage,
  }.merge({
   :wiki => spec.metadata["wiki_url"],
  }).delete_if {|_, url| 
    # validating it's a url is sensible, no?
    begin
      not URI(url).absolute
    rescue URI::InvalidURIError, ArgumentError
      true
    end
  }
```
  attributes =  { :home => spec.homepage }
  attributes.merge({
    :wiki => spec.metadata["wiki_url"],
    :docs => spec.metadata["documentation_url"],
    :mail => spec.metadata["mailing_list_url"],
    :code => spec.metadata["source_url"],
    :bugs => spec.metadata["issue_tracker"]
  }.delete_if { |_n, v| v.nil? }) if spec.metadata

can we also discuss metadata keys we'll be promoting? 

mapping wiki to wiki_url make sense.  code to source_url.. I'd prefer code -> code_url, docs -> docs_url, mail -> mail_url, bugs -> bugs_url.  Now, if we had a mapping, we could accept source_url or code_url to map to code.  YMMV