use parseLink instead, and allow query on all refs

[mmckegg]

I hastily merged and published #15 as v2.10.0, but now I realise that @dominictarr was suggesting that we allow query on all ref types.

This PR adds support for handling query strings on all ref types, and adds a parseLink method which allows you to access this in the form of {link: "id...", query: {param: "value"}}

So I have unpublished 2.10.0 and submit this instead. The reason I unpublished is that this PR contains a breaking change to 2.10.0 where I'm using a generic parseLink instead of parseBlob.

[mmckegg]

Hmm, decided to change this so that it doesn't affect any existing methods.

the various isBlob isFeed, etc only detect the key itself, not the query. First parse with parseLink then give to ref.type to find out what type of link has been parsed

[mmckegg]

Okay, I'm going to merge this.

This is much safer than last time as it doesn't affect any existing code. All it does now is add a new function parseLink that handles parsing query strings on the end of ssb ref IDs.

[mmckegg]

Released as ssb-ref@2.11.0 🎉

Hopefully less 👻 this time 😆

[dominictarr]

@mmckegg :+1:

I was a little confused because it looked like parseLink accepts a feed/msg/blob id with a ? then anything appended https://github.com/ssbc/ssb-ref/pull/16/files#diff-168726dbe96b3ce427e7fedce31bb0bcR5 ?

but then I saw it passes that to Querystring.parse https://github.com/ssbc/ssb-ref/blob/680ed76fea503a60a4dc549a42557456dafbf99f/index.js#L161-L170

hmm, I guess ?anything is a valid query string with an empty value

[dominictarr]

am just wondering if this should be more restrictive, what shouldn't this permit? If we let something we don't want sneak in, we'll have to support it down the road if people start using it.