Since patterns like /foo/./bar don't match paths paths like /foo/bar,
throw an error if the client tries to reply or create a rule with such a
construction clearly in the pattern. That is, if the pattern contains
`/./` or `/../`, or if it ends with `/.` or `/..`.

Notably, we do this on the raw pattern string, similarly to how we
validate that the pattern begins with a `/`: we don't consider whether
all alts in a leading group happen to start with `/`, we simply throw an
error if the first character is not `/`.

In this case, we take a more lenient (but similarly lazy) approach: if
there's a literal `/./` or `/../`, or trailing `/.` or `/..`, then an
error is thrown. As long as there's something interrupting the `/` or
end of the pattern string (e.g. a group), we consider that fine. For
example, we allow `/foo/.{,bar}` even though technically this renders to
the variants `/foo/.` and `/foo/.bar`, where the former is undesirable.

We may reconsider this in the future, but checking whether any rendered
variant contains `/./` or `/../` in general requires fully rendering
each variant and checking each one, which we do not do at parse time,
and one nearly always has at least one pattern which is capable of
matching something valid (an exception being the pattern `/foo/.{,}`,
for example). But the user must fairly deliberately shoot themself in
the foot to end up in that situation.

Again, the worst case if a pattern which is "bad" in this way gets past
validation is that we end up with a path pattern which is incapable of
matching any paths. This is undesirable, but not problematic.

Signed-off-by: Oliver Calder <[email protected]>

Co-authored-by: Zeyad Yasser <[email protected]>