Handle URL encoding/decoding

Happy path works well. Need to think about the use of unsafe in fetching parameters.

We want to avoid duplicate UTF-8 safety checks.

With out current approach, we could just have 2 methods for searching. Then we'd cut out the if statement per search.

API isn't set in stone. Keep it as is for now? Issue with the Path API is that if we try to search decoded, then search non-decoded, we'll use the decoded version.

Maybe force everyone through the encoded path? How would that work for HTTP-adjacent use cases? Like gRPC (Tonic)?

EDIT: Removed regex. Wasn't confident in the implementation.

Marking this implementation as 'good enough' for now. Not like I'm releasing this code yet, anyways.

Just need to add more tests to showcase nuances in encoding specs.

CodSpeed Performance Report

Merging #110 will degrade performances by 29.73%

_{Comparing 8-investigate-url-encodingdecoding (60a3fd6) with main (4924ae1)}

Summary

❌ 11 regressions ✅ 5 untouched benchmarks

⁉️ 2 dropped benchmarks

:warning: Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	`main`	`8-investigate-url-encodingdecoding`	Change
❌	`matchit benchmarks/matchit`	8.1 µs	11.2 µs	-27.7%
❌	`matchit benchmarks/ntex-router`	28.1 µs	31.6 µs	-11.13%
❌	`matchit benchmarks/path-tree`	10.8 µs	13.6 µs	-20.64%
⁉️	`matchit benchmarks/regex`	53.9 µs	N/A	N/A
❌	`matchit benchmarks/route-recognizer`	39.7 µs	42.3 µs	-6.26%
❌	`matchit benchmarks/wayfind`	8.1 µs	10.1 µs	-20.19%
❌	`matchit benchmarks/xitca-router`	8.8 µs	12.5 µs	-29.73%
❌	`path-tree benchmarks/matchit`	61.4 µs	75.3 µs	-18.46%
❌	`path-tree benchmarks/ntex-router`	231.2 µs	245.5 µs	-5.83%
❌	`path-tree benchmarks/path-tree`	72.9 µs	86 µs	-15.28%
⁉️	`path-tree benchmarks/regex`	715.1 µs	N/A	N/A
❌	`path-tree benchmarks/wayfind`	42.5 µs	49 µs	-13.33%
❌	`path-tree benchmarks/xitca-router`	68.3 µs	82.2 µs	-16.96%

DuskSystems / wayfind