Correct processing of non-string members of a base URL record

[jeremyroman]

Some of these values may be null (or in the case of port, an integer) and must be converted to strings before they can be applied to URLPatternInit.

The conversion of the port to an integer is also necessary in the encoding callbacks.

Addresses #202, at least in part.

• [x] At least two implementers are interested (and none opposed):
  • Google Chrome
  • n/a (change is simply fixing a bug in a non-controversial way)
• [x] Tests are written and can be reviewed and commented upon at:
  • n/a (this is a fix to how the spec expresses this, but does not represent a behavior change, and existing tests cover this behavior)
• [x] Implementation bugs are filed:
  • Chromium: n/a (believed to work correctly in Chromium)
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1731418 (vendor does not yet implement the spec)
  • WebKit: [no known URLPattern bug] (vendor does not yet implement the spec)
  • Deno: n/a (no reason to believe a change is required)
  • kenchris/urlpattern-polyfill: n/a (no reason to believe a change is required)
• [x] MDN issue is filed: n/a (change is on a spec detail not expressly documented)
• [x] The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[jeremyroman]

@annevk I think we need a second implementer interest even for little fixes like this, right? Is WebKit cool with this?

[annevk]

I think for cases where you are just fixing a bug in the standard when there are no conflicting implementations out there you can use your best judgment and carry on.

Though perhaps the extra waiting time helps as I see you fixed another another nit. :-)

Anyway, looks good.

[jeremyroman]

Thanks Anne, noted for future changes in this vein.