Add Support for Parameter Suffixes

[ibraheemdev]

Adds support for parameters with static suffixes. For example, /{foo}.png.

The implementation allows parameters with and without suffixes to co-exist. For example, /foo, /{foo}.jpg, and /{foo}.png are not considered overlapping. This works by adding another layer to the tree after parameter nodes, representing suffixes before the next route segment. The appropriate suffix is determined using a linear search.

Additionally, the restriction of a single parameter per route segment still remains. This means /{foo}.{bar} is not supported. Arbitrary parameters without a / anchor can become quite complicated in terms of backtracking (similar to #41 (comment)), so multiple parameters are unlikely to be supported.

Resolves #17.

[scottlamb]

Thank you! I've been looking forward to this.

I have a case in which I'd like to use this for two file suffixes, one of which is a prefix of the other. It appears to fail as follows:

#[test]
fn wildcard_suffix2() {
    MatchTest {
        routes: vec![
            "/{foo}.ts",
            "/{foo}.tst",
        ],
        matches: vec![
            ("/bar.ts", "/{foo}.ts", p! {}),
            ("/bar.tst", "/{foo}.tst", p! {}),
        ],
    }
    .run();
}

---- wildcard_suffix2 stdout ----
thread 'wildcard_suffix2' panicked at tests/match.rs:78:13:
assertion `left == right` failed: /{foo}.tst
  left: Err(Conflict { with: "/{foo}.ts" })
 right: Ok(())
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[ibraheemdev]

Yeah that seems reasonable, I think we can support it.

[ibraheemdev]

I updated the implementation to support overlapping suffixes, such as /foo, /{foo}.jpg, and /{foo}.png. This does impose a very minor performance regression by introducing an extra node after any route parameter, even without a suffix. Routes without suffixes are special cased so it is possible to avoid this, but it's incredibly minor so it's not very relevant.