Tplink-cloud-api

What's Changed
* Widen requirement version restrictions by ShayBox in https://github.com/piekstra/tplink-cloud-api/pull/49
* move to fully asyncio interface by thisiscam in https://github.com/piekstra/tplink-cloud-api/pull/53
* v4.0.0 Fully Async by piekstra in https://github.com/piekstra/tplink-cloud-api/pull/54

New Contributors
* ShayBox made their first contribution in https://github.com/piekstra/tplink-cloud-api/pull/49
* thisiscam made their first contribution in https://github.com/piekstra/tplink-cloud-api/pull/53

**Full Changelog**: https://github.com/piekstra/tplink-cloud-api/compare/v3.0.0...v4.0.0

This release separates login functionality for the `TPLinkDeviceManager` which can now be constructed without a `username` and `password`. In order for requests to work properly when a username and password are not provided on construction, either the new `login` function or `set_auth_token` will need to be called.

As a part of this change, an error is no longer raised when providing a `None`-valued username or password to the `TPLinkDeviceManager` constructor.

**Bug Fixes**
* The HS100 device does not have EMeter capabilities - this change addresses that.

**New Dependencies**
* `freezegun==1.1.0` - only for tests; allows mocking a date for testing functions that use datetime

**New Features**
This change introduces two new methods for all devices, get_runtime_day and get_runtime_month.

With get_runtime_day, you will see all runtimes in minutes for the specified year and month (where data is available) and can use that to look at the current day's runtime since the current value is contained in that list under the current year, month, day.

Daily averages and total runtimes as seen in the Kasa app can be calculated based on the raw data.

For example, total runtime for the past 7 days would be calculated by summing time for each day starting from the previous day (not today) through 7 days before that and dividing by 60 to get a value in hours. Daily Average over that period would simply be that value divided by 7.

For the past 30 day's values, follow the same method but sum all of the time data available from the current month (excluding the current day) as well as the previous month (at most 30 days of data in total across months is retained by TP-Link and that includes the current day). Take the summed value and divide by 60 to convert the units to hours and that will be the Total Runtime as seen in the app. For the Daily Average of the past 30 days, divide by 29 instead of 30 and you should see the same value as the app (though the app either rounds or truncates the value to 1 decimal place).

**Bug Fixes**

* emeter device `get_power_usage_realtime` returns `None` when device is offline instead of throwing an exception
* emeter device `get_power_usage_realtime_async` returns `None` when device is offline instead of throwing an exception
* emeter device `get_power_usage_day` returns `None` when device is offline instead of throwing an exception
* emeter device `get_power_usage_day_async` returns `None` when device is offline instead of throwing an exception
* emeter device `get_power_usage_month` returns `None` when device is offline instead of throwing an exception
* emeter device `get_power_usage_month_async` returns `None` when device is offline instead of throwing an exception

Introduces a new class, `TPLinkDeviceScheduleRuleBuilder` which allows a rule to be built or modified . Examples of this are provided in the README.md

New methods exposing device functionality around rules for a device schedule. Rules can not be retrieved by their ID, new rules can be added, and existing rules can be deleted with the following:

* `get_schedule_rule(rule_id)`
* `add_schedule_rule(rule)`
* `delete_all_scheduled_rules()`
* `delete_schedule_rule(rule_id)`