Links improvements

[sgleizes]

This PR addresses the same issues than #26, but goes a little further.

Included:

• Fix top level links type
• Add support for string links

There are several ways this could have been implemented, feel free to comment if you think the one I went with does not fit well. Indeed it changes the way links are created because of the embedded link field.
The embedded field could be avoided at the cost of a less elegant implementation, but if you don't want to break the public API that would be the way to go.

I have another series of improvements I am working on that I want to propose (mainly on errors) and some of them cannot be done without changing the current data structure. I am therefore interested in your opinion on the matter to see if we can incorporate breaking changes in v1 or in a separate branch.

[derekdowling]

First off, thanks for doing this. I let the initial Link logic get merged because I hadn't implemented any of it and was just glad to have a starting place for others to build off of, so I am glad someone is revamping/improving it.

Rather than embedding type link. I'd prefer you just sub-type it within the Marshaling logic itself such as here to get around the recursive marshaling issue: https://github.com/derekdowling/go-json-spec-handler/blob/master/relationship.go#L34. Are there any issues with doing that in this case? It might make the (Un)Marshaling logic a bit noisier, but it keeps the rest of the logic that users are more likely to interact with cleaner.

[derekdowling]

Thanks for the tests!

[sgleizes]

That's indeed the better way to go, it's done.

[derekdowling]

Looks good. Thanks!