Fix parsing URIs with empty path segments

[patrickbkr]

Fixes croservices/cro-http#197, fixes #39.

[lizmat]

This is changing semantics, is it not? Should ~$_ be there?

[patrickbkr]

I don't have a firm understanding of all the regexy bits going on.
Before the change it errored out if there was no pchars. Now it's to be decided if in that case the non-pchars text should be discarded or kept. Irrespective of what we do, we'll change the semantics. My bet was that we want to keep it. What do you think?

[lizmat]

I guess we need to be clear with what original path it creates the errors, what the regex / token is that created the Match object, and what the result needs to be.

All of that is pretty unclear to me :-(

[patrickbkr]

segment is literally only

token segment {
    <pchars>?
}

So it doesn't make a difference. What do you think would be cleaner? ~$_ or ''?

[lizmat]

In that case, I'd say: $result ~= '/' ~ (~$_ if $<pchars>) for @$<segment>; ?

since there's nothing else in the token, we can safely stringify the whole Match object if <pchars> matched.

[patrickbkr]

What does $<pchars>.ast return? If it's the thing method pchars() maked, then ~$_ is different from $<pchars>.ast.

[lizmat]

Ah, duh :-) Forgot about the .ast part. $result ~= '/' ~ (.ast with $<pchars>) for @$<segment>; then?

[patrickbkr]

There you go.