Generalise SegmentResult

[alexfmpe]

Ran into a non-urls usecase where I wanted to use ([Text], ByteString) instead of ([Text], Map Text (Maybe Text)) and realized the groundwork for #989 allowed me to use ([Text], q) as long as I relaxed the type signatures so I pulled that bit into this separate, more conservative PR.

The tutorial describes the PageName version of pathComponentEncoder. Should that be updated with this PR or do we keep it simple?

I have:

• [ ] Based work on latest develop branch
• [ ] Followed the contribution guide
• [ ] Looked for lint in my changes with hlint . (lint found code you did not write can be left alone)
• [ ] Run the test suite: $(nix-build -A selftest --no-out-link)
• [ ] Updated the changelog
• [ ] (Optional) Run CI tests locally: nix-build release.nix -A build.x86_64-linux --no-out-link (or x86_64-darwin on macOS)

[alexfmpe]

Ended up also locally defining a variant of queryOnlyEncoder with the more general type.

I wonder if this should be more of a generalise-query-type thing.

In theory we could do the same for path, so instead of PageName everywhere, unless url-specific we'd instead have ([fragment], query) but I don't actually have a use-case for that so hard to tell what exactly to generalise to. What even is a generic path afterall?

At least allowing () locally as the query type seems pretty convenient and common