Special characters in password are double-encoded when client initialized with host as a string

Steps to reproduce:
* Have a password that includes a special character such as `@`. For example, `p@assword`.
* Incorporate the password into a URL string to be passed to the client. Since "@" is a delimiter in URLs, it has to be percent-encoded, and you end up with a URL like `http://user:p%40ssword@127.0.0.1:9200/`.
* Initialize a client and try to search with it: `Elasticsearch::Client.new(url: 'http://user:p%40ssword@127.0.0.1:9200/').search('...')`

Such a request will be rejected by the server because the password is percent-encoded again, presumably with the assumption that the original password value was not already percent-encoded.

The issue appears to be a combination of the approaches for parsing the host information when the client is initialized and generating the URL for the full request. In particular, the initial parsing (see https://github.com/elastic/elasticsearch-ruby/blob/v7.3.0/elasticsearch-transport/lib/elasticsearch/transport/client.rb#L202) uses `URI.split` in the case of a string, which does not perform any unescaping. That is, the password attribute will have the value `p%40ssword` and not `p@ssword`. Then, at https://github.com/elastic/elasticsearch-ruby/blob/v7.3.0/elasticsearch-transport/lib/elasticsearch/transport/transport/connections/connection.rb#L46, the password is encoded again. I assume the situation also applies to usernames in URLs.