Make it easier to switch environments WITHOUT access to Environments page

[#1]

It'd be wonderful to have a console code snippet (similar to DTM's "localStorage.setItem('sdsat_stagingLibrary', true)") or even have it added to the Launch Switcher plugin (which currently requires the user navigate to Launch's Environments page).
Use case: if we want a third party to be able to test their tag is firing correctly before we publish it.... they don't have access to our launch, nor to our lower environments. in DTM I could just tell them "use this snippet and reload the page", but for Launch, the best I can do is get them to install the Experience Cloud debugger extension (Adobe Experience Cloud Debugger - Chrome Web Store ), tell them to go to "Tools", and manually insert the full embed code I provide them.

I understand the thing that makes this tricky is that folks can have multiple dev environments so the code/extension doesn't always know where to pull dev libraries from... if we'd need to make one as our permanent "for external testing" environment or something (so it'd look more like it did in dtm... launch-ENXXX12345.min.js for prod, launch-ENXXX12345-staging.min.js for staging, and launch-ENXXX12345-dev.min.js as my permanently-easily-accessible-by-console-or-extension dev library), I could work with that. Or if the snippet/extension made me manually input my library ID or something, kinda similar to the Adobe Experience Cloud debugger currently does (but without all the extra bloat of that tool):

Or if I could generate a testing link (kinda like how GTM does it) so that if a tester went to www.domain.com?adobeTest=true&adobeLibrary=ENXXX12345-staging it would use that library and maybe even have _satellite debugging turned on automatically...

At bare minimum, if there was a snippet/extension to switch from prod to staging (since that IS a more static link than dev)- even that would help.

Really at this point though, I just need ONE option to use for these situations, short of me telling them to install switcheroo.

[#2]

Even if dev environments can only return an index (as to hide their names if sensitive), it would be handy to be able to query, and select.

[#3]

Best idea ever!  To add on to this, our staging environments are usually behind firewalls that require copious amounts of time to sway our IT teams to punch holes for said vendors.   Google tag manager makes this delightfully simple with a click of a button, and BAM! vendors are viewing all unpublished code on our production environement.

[#4]

So there's two discreet problems that need to be solved here:

1. Identifying which environment to switch to
2. Intercepting the request for the prod environment and redirecting it to your specified environment

Re: Problem #1

We have come up with two ways to solve this one.

1. Emit one or more environment IDs into the libraries.  We could up with some mechanism for you to designate a single environment that you want to use for testing, or we could just emit all of them.  We don't really want to do this because it'd make the library bigger for all users in exchange for a slight benefit for only a few people at most.
2. Rely on the user to specify the environment ID in some way.  Embed codes are explicit.  Environment ID is less so, but could still be done if we assume you're using the built-in hosting option.

Re: Problem #2

DTM solved this problem by essentially writing a redirect into every production library.  It would check local storage for the `sdsat_stagingLibrary` flag and if it was set, it would hijack the library load and load up the staging library instead.  This always felt kinda icky and we deliberately did not do this with Launch.  Which leaves us without the library itself as a mechanism for redirecting.

We could ask you to implement something in a loading snippet that checks a query param or a local storage item or something and then load up a different library based on that, but there's actually nothing stopping users from doing this themselves, and like 1.1, it felt overly complicated for the nature of the problem.

We could build something on the edge with something like CloudFlare workers that could perform the same logic and return an appropriate library, but there's a cost there and building out an entirely new hosting solution to solve this problem is not in our cards right now.  Something similar to this is actually how GTM solves this problem, but they also have access to the Google edge.

Finally, you can look at browser extensions or similar localhost type tools (Charles, etc).  And since we already have the Adobe Experience Cloud Debugger, this seems like the simplest path forward.

So we think it is a good idea to modify the Adobe Experience Platform Debugger to make it simpler to swap - like use an environment ID instead of the full embed code for example - and we can write a guide with step-by-step instructions for swapping, but that's about as far as we're willing to take this one.