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.
This is pretty close to just testing that `update_attributes!` works.  Why not put the 'existing' links hash in the before block, then in the test, create the linkset with them, update from a gemspec with no links, and confirm that the values didn't change with a simple iteration over the assertion?