Added support for disabling certificate validation when connecting to…

[devloch]

… stash, and ability to prompt for username and password when logging in with DeoVR

I found when I went to use stash-vr-companion, it failed due to using HTTPS on my stash instance (certificate validation errors). While theoretically the app could be configured to set custom trust stores, that's a lot of work when in practice the only endpoint it's connecting to is the one you specify that's presumably on your localhost or local network.

Similarly, stash-vr-companion doesn't allow for username/password, but I believe DeoVR does support basic auth flows.

I haven't tested these flows yet (don't have docker locally, and my server can't do builds), but I'll fake update the docker image later and test.

[devloch]

Ran into exceptions when pulling down cache info, so I must have missed something. When I connected non-TLS to load the initial cache, then switched back to TLS, it connected (and established that the cache was loaded) totally fine.

Strangely, it seems like ['paths']['screenshot'] returns a non HTTPS URL (when looking directly after the graphql call, so it isn't like it's being tweaked in app.py).
http://IP:port/scene/919/screenshot?1658361816

However when I do network debugging of typical stash browsing, [paths][screenshot] is the proper
https://IP:port/scene/...

Or when I'm browsing via a domain name,
https://domain:port/scene/...

So I wonder if this is actually an issue with Stash, where if a graphql query is made via api key (or some other feature unique to these queries but not my web browser) it doesn't properly map the hostname.

Sorry about the premature pull request, thought it would be a simple test and fix! When I get a chance I might take a look a bit more.

[devloch]

Confirmed it's partially an issue with stash, which returns "http" in various use cases (outside of the deovr-plugin as well) even when the server is on https.
stashapp/stash#2764

[devloch]

Alright, I failed at getting username/password or hosting it as TLS to work, and those should probably be a separate set of change sets anyways.

But I added a sort of gimmicky header (like, it's not technically an appropriate header for what stash-vr-companion is doing) that works around stash#2764, and confirmed/tested that this works with a HTTPS hosted stash.