createClient url+tls invariant violation check

[dearlordylord]

Description

on url rediss:.. + tls: false passed or on url: redis: + rls: true passed, the lib blows up during connection with a non-descriptive error

I explicitly check for this invariant violation during initialisation

• parseOptions was added to make it testable and to avoid the pesky this.#selectedDB = options.database; in #initiateOptions I dare not to touch
• parseOptions is supposed to check cross-field invariants that parseUrl alone won't be able to do
• parseUrl explicitly states on type-level that it affects tls (it did this anyways, implicitly, by blowing up the connection on wrong tls passed)
• parseOptions mutates its arguments as well as returns the mutated value in accord with how #initiateOptions was implemented (let me know if you'd like me to not-mutate the argument; I'd actually prefer it this way)
• the technical change is that initialization will now set tls explicitly to boolean if it wasn't set but an url was passed: reasons are both technical (I needed to test without changing your interfaces much) and logical: tls undefined with URL: redis[s]: seems to be an incorrect invariant anyways

Options:

• not throw any errors, silently overriding user-given value - I prefer to fail-fast, because the instance will fail anyways on connection

---

Checklist

• Does npm test pass with this change (including linting)?
• Is the new or changed code fully tested?
• Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?

[dearlordylord]

union is a bit wordy, please guide me where you'd like to define an interface if you think it's not ok to inline that

[dearlordylord]

"DRY enough": at this point protocol is a literal union and won't accept anything except those two literals

[dearlordylord]

maybe better to put before this.#selectedDB = options.database but it's a private method use in a constructor anyways?