fix(runtime): Non-standard Concatenation Algorithm in BOM URL polyfill

[TechQuery]

这个 PR 做了什么？

修正 Taro runtime 中的 polyfill，对齐 Web URL 标准中的路径拼接算法：https://developer.mozilla.org/zh-CN/docs/Web/API/URL/URL 。

这个 PR 是什么类型？

• 错误修复(Bugfix) issue: fix #
• 新功能(Feature)
• 代码重构(Refactor)
• TypeScript 类型定义修改(Typings)
• 文档修改(Docs)
• 代码风格更新(Code style update)
• 其他，请描述(Other, please describe):

这个 PR 涉及以下平台：

• 所有小程序
• 微信小程序
• 支付宝小程序
• 百度小程序
• 字节跳动小程序
• QQ 轻应用
• 京东小程序
• 快应用平台（QuickApp）
• Web 平台（H5）
• 移动端（React-Native）
• 鸿蒙（harmony）

[yoyo837]

个人觉得这个不如之前的写法清晰易读

[TechQuery]

个人觉得这个不如之前的写法清晰易读

在同一份数据涉及的操作不多时，展开写可能更清晰；但分支情况多了，代码行数多反而不利于阅读，格式化规范的三目运算符则能清晰展示不同条件和分支的相互关系。

[Single-Dancer]

个人觉得这个不如之前的写法清晰易读

在同一份数据涉及的操作不多时，展开写可能更清晰；但分支情况多了，代码行数多反而不利于阅读，格式化规范的三目运算符则能清晰展示不同条件和分支的相互关系。

现在的三目运算符嵌套层级太深了，可读性有点差，要不还是改成 if/else

[TechQuery]

个人觉得这个不如之前的写法清晰易读

在同一份数据涉及的操作不多时，展开写可能更清晰；但分支情况多了，代码行数多反而不利于阅读，格式化规范的三目运算符则能清晰展示不同条件和分支的相互关系。

现在的三目运算符嵌套层级太深了，可读性有点差，要不还是改成 if/else

这段代码其实非常清晰，条件均为 url.startsWith() 或 pathname.endsWith()，结果多为 origin 与其它变量拼接，单词上下整齐、缩进错落有致，很容易看出不同情况下哪些部分变了、哪些没变，而 if else 的等效代码会很长，其实不利阅读：

    fullUrl = url
      ? url.startsWith('//')
        ? protocol + url
        : url.startsWith('/')
          ? `${origin}${url}`
          : pathname.endsWith('/')
            ? `${origin}${pathname}${url}`
            : `${origin}${pathname.replace(/[^/]+$/, url)}`

如果 Taro 团队非常在意三目运算符，应该在 ESLint 中设置禁用规则，在 CI/CD 层面拦截 PR 中的相关代码，否则只要单元测试通过，其它风格偏好都是可以接受的，因为 @yoyo837 @Single-Dancer 的理由只有“我觉得可读性差”、我觉得“可读性好”的主观感受，没有客观标准。