feat(ext/webstorage): use implied origin when --location not set

[kitsonk]

Closes #11882

This differs a little bit from the proposal, in that there is no window.location set at all when --location is not supplied. That behaviour stays the same. Instead though, the storage origin is determined fully on the Rust side and not exposed at all in the runtime. The algorithm is:

• Use the origin of the --location if a --location is passed (unless the --location has an opaque origin, and in this case localStorage will be disabled)
• If no --location is passed, but there is a config file, use the absolute path to the config file as the "origin", meaning that programs that share the same config file, will share the same localStorage.
• If no configuration file is present, use the URL of the main module. Currently for the REPL and test, a synthetic module is generated based on the cwd when Deno starts. This means executing the REPL from the same cwd means subsequent invocations will share storage.

I need to write tests for it. Also noticed that inspecting window.localStorage or window.sessionStorage isn't working, because the proxy doesn't properly deal with the inspect symbol.

I will also add documentation to the manual once we have merged this PR.

This is going to be a little bit of a breaking change, because we were setting the storage path based on the full --location and not the origin of the --location, meaning that --location https://deno.land/x/a.ts and --location https://deno.land/x/b.ts would not share the same storage, but to be well aligned to the web platform, they should. Between the config path and the main module implied storage origins, there should be sufficient alternatives to allow flexibility so that we can better align to the web platform.

[lucacasonato]

There is some conflicting info in the PR description:

Use the origin of the --location if a --location is passed

This is going to be a little bit of a breaking change, because we were setting the storage path based on the full --location and not the origin of the --location

Which one is it? Should be the first IMO. EDIT: code says it is the first one, so doesn't look like a breaking change to me.

[lucacasonato]

LGTM. We definitely need to add docs for this to the manual.

[kitsonk]

@lucacasonato currently (main) the full --location URL as a string is being used, the PR changes it to use the ascii serialized version of the origin --location URL.

[lucacasonato]

Oh I see. Good catch.