Consider changing Response's url so it includes a fragment

[annevk]

I initially bundled this with #505 and I now think that was a mistake. We should consider this separately. We also don't need to change XMLHttpRequest's responseURL as that's a legacy API. An obvious alternative here would be to introduce a separate getter for the propagated fragment if we deem it too risky.

Not exposing this prevents correct usage of fragments in userland. (I'm not sure there is much of that as we haven't seen any complaints to date, but it seems consistent with the extensible web principles to give userland the same capabilities the browser has.)

I will adjust web-platform-tests/wpt#7261 per our decision.

cc @wanderview @yutakahirano @KershawChang @youennf @domenic @jasnell

[wanderview]

I feel like I have seen a couple developer complaints over the years, but I don't have references handy.

[yutakahirano]

I don't have a strong opinion. I would like to maintain my previous position,

I guess that not many pages will be broken. Assuming that, if other browser vendors are fine with the idea I can change the behavior.

[stof]

See hotwired/turbo#825 and hotwired/turbo#211 for reports in @hotwired/turbo that are direct results of this limitation as Turbo cannot know that the final URL being loaded has a fragment.

[RafaelKr]

We also just ran into this when using Turbo.

It would be very helpful to at least have a possibility to receive the fragment from the fetch Response, maybe with the separate getter, as @annevk suggested.