Add support for negative float strings

Add tests for #118

Fix links in the documentation

Add Elasticsearch5 to search scheme

Add Elasticsearch7 to search scheme

Use default option in Env.bytes()

Currently, if a `.env` file isn't found by the read_env() classmethod,
it raises a UserWarning. Based on Python's logging guide,
warnings.warn() is only appropriate to be raised in library code if the
issue is avoidable and the client application should be modified to
eliminate the warning.

Conversely, it recommends logging.warning() if there is nothing the
client application can do about the situation, but the event should
still be noted (see ref1).

In this particular case, the function is working with `.env` files that
should only ever exist in development environments, which means that
the function will erroneously warn the consumer in production and
staging environments.

With this in mind, I believe the most sensible thing to do would be to
convert read_env from using the warnings module to using the logging
module. Additionally, since the lack of a `.env` file is going to occur
regularly during normal operation of the program, I also believe that
this should be downgraded to an INFO level message from a WARNING
level message.

#243 requests that the .env file be made
optional, and as far as I can the .env file is indeed optional, it's
just that a UserWarning is being raised instead of a logged message.
With that in mind, I'm referencing it as being closed by this change.

ref1: https://docs.python.org/3/howto/logging.html#when-to-use-logging

fixes: #243

…tional

Stop raising UserWarning if .env file isn't found

See #200 for details

Safely evaluate a string containing an invalid Python literal

…242)" (#326)

This reverts commit e04667c.