fix(path): fix common() results that depend on the order and/or number of input paths

[jviide]

This pull request addresses (and adds tests for) cases where common() returns different values depending on the order and/or number of the input paths, when different results may not be intended.

For example in this case it's probably expected that both cases return an empty string:

> common(["/", ""], "/")
'/'
> common(["", "/"], "/")
''

In the next case the result depends on the number of paths, even if the paths are all equal. The expected result in both cases is likely '/foo/bar':

> common(["/foo/bar"], "/")
'/foo/'      // missing 'bar'
> common(["/foo/bar", "/foo/bar"], "/")
'/foo/bar/'  // extra slash at the end

This pull request adds a variable (append) to track whether a separator should be appended to the end of the result string. Early returns are removed to keep this tracking consistent. The performance doesn't seem to degrade in the following tested case:

Deno.bench("original common()", () => {
  commonOriginal([
    "./deno/std/path/mod.ts",
    "./deno/std/fs/mod.ts",
  ], "/")
});

Deno.bench("modified common()", () => {
  commonModified([
    "./deno/std/path/mod.ts",
    "./deno/std/fs/mod.ts",
  ], "/")
});

Results for Deno v1.41.0, MacOS 14.3.1:

benchmark              time (avg)        iter/s             (min … max)       p75       p99      p995
----------------------------------------------------------------------- -----------------------------
original common()     225.89 ns/iter   4,426,966.2 (219.21 ns … 255.68 ns) 227.8 ns 246.43 ns 247.09 ns
modified common()     196.07 ns/iter   5,100,328.9  (188.82 ns … 217.8 ns) 196.75 ns 216.05 ns 216.22 ns

[CLAassistant]

All committers have signed the CLA.

[kt3k]

All suggested changes seem reasonable to me. Thanks for working on this!