This new login flow is an improved version of org.matrix.login.jwt

The later
  * required the OICD provider's public key to be written to the
    homeserver.yml
  * accepted only one possible issuer of JWT tokens
  * has its own section in homeserver.yml and completely ignores
    'oidc_providers'
  * Used the 'sub' from the JWT as localpart of the user's address
  * required the JWT to be sent in the body of the login request
  * Created a new user if it wasn't found - no configuration possible

The new login flow (called org.matrix.login_oidc_jwt)
  * uses section 'oidc_providers' from homeserver.yml
  * accepts all configured providers as (possible) issuer of JWT tokens
  * uses the configured 'jwks_uri' to fetch the provider's public key
  * fetches the JWT either from the body and if there's none it checks
    the 'Authentication' http header
  * extracts iss/sub from JWT and searches the 'external_ids' of the
    user database. If such an entry is found the user is authorized;
    otherwise the user is rejected

New config parameters in section 'oidc_providers':

  * sso_jwt_enabled (boolean) - allows an admin to disable the new
    login flow for a given oidc_provider while at the same time keep the
    standard sso login flow for the oidc_provider allowed

  * standalone_jwt_audience (string) - if the new JWT login flow is
    allowed for an oidc_provider then this parameter can be used to
    enforce a specific audience claim to be contained in the JWT
    (otherwise the login attempt will be rejected)

Signed-off-by: Hannes Lerchl <hannes.lerchl@googlemail.com>

Signed-off-by: Hannes Lerchl <hannes.lerchl@googlemail.com>

* generated sample_config
* used black to format code
* fixed tyoe hint findings of mypy