This avoids grey or transparent flashes on start

Note that this commit will break some stuff for non-embedded cases, for now.

refs #6814

Quoting the reporter:
| According to include/vlc_access.h, access_t.psz_location is "URL with
| the scheme stripped". But in http module, schema stays there after
| 302 redirection. That may cause httplive module try to access URL like
| "http://http://host/path".
Pointed-out-by: bbcallen <bbcallen@gmail.com>

If a certificate does not validate, the user will be given the option
to accept it manually. GnuTLS will then store the certificate in its
known hosts database.

This will be used for fine-grained GnuTLS stored public keys,
i.e. SSH-like authentication on first use.

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Close #7529

Keeping the credentials container saves some times, as we do not need
to load and parse all of the 100+ Certificate Authorities again.
In the future, it will also avoid reloading the stored public keys
(i.e. security exceptions), or asking for user confirmation again.

Given how the HTTP access is written, the credentials are now preserved
upon seeking. Unfortunately, they are not recycled across redirections
as access_t.p_sys gets destroyed internally. This also does not work
across multiple inputs - support from the instance or input manager
would be required.

The TLS plugin now supports reusing the same set of credentials for
multiple sessions also on the client side.

Support for custom certificates will be better addressed with the
stored public key support in the GnuTLS library (in latter commit).

Support for private keys on client side was practically useless.

GnuTLS system trust supports more systems, and supports Linux and
Windows better, than the old custom code.

This enables the use of vlc_custom_create() and, later, sharing more
code between server and client sides.

There are no (other) reasons for the GnuTLS plugin to link against
libgcrypt. Since nettle has been the default back-end for GnuTLS for
ages, this old code has become more harmful than good.

Besides, this code was not sufficient to really address the thread
safety issues in libgcrypt (since it is also used via other paths).

refs #6897
Signed-off-by: Hugo Beauzée-Luyssen <beauze.h@gmail.com>

So we have chance to try other streams instead of just fail.
Fixes #6898
Signed-off-by: Hugo Beauzée-Luyssen <beauze.h@gmail.com>

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>