don't duplicate persistent share links when importing

[jwunderl]

When loading a persistent share link, check if we already have the header for it, and if so load it. Here's a build:

https://arcade.makecode.com/app/1542f0098ae8cd9614e77e373590f0623ff8129d-57379544fb

@eanders-ms question, when you first login to a browser do we sync all the headers? I tried to check if this would have trouble immediately following logging in or cache being cleared, but the project I was testing always ended up being loaded while the page reloaded so I couldn't test if there was a case where loading old projects could run into an issue or anything of the sort.

[eanders-ms]

@jwunderl yes, when a user logs in we sync all cloud headers. It's asynchronous, of course, so there might be a bit of a race condition in the scenario where:

• headers aren't synced
• the user clicks "remix" from multiplayer
• the editor loads before the headers are synced.

[abchatra]

Probably should wait for the headers to load then?

[eanders-ms]

@jwunderl we fixed this a different way, with the no-cache header, correct? Can we close this?

[jwunderl]

That fix was for a cahcing issue if you open the same persistent link multiple times; this pr would make it so that when you import a persistent share link, if you were the one who originally authored the project / created the link, it opens the existing project instead of cloning the project (so e.g. opening the link as the author, making a change, and resharing updates the link instead of forking the project)

I believe we had a user report being surprised that it created a copy rather than 'continuing' their project from the latest version as it was labelled persistent. That said, we might consider this as a similar case to #9499 and think of it as an intentional copy / suggest the user search for the existing project if they want to update the link. We could also put up a 'continue or copy?' modal but I feel like we've been avoiding those