Refactored `Site.expandtemplates` to use the updated API, addressing
deprecation warnings in recent MediaWiki versions.

The older API triggered the following warnings:

```
WARNING:mwclient.client:Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes. Use [[Special:ApiFeatureUsage]] to see usage of deprecated features by your application.
WARNING:mwclient.client:The parameter "generatexml" has been deprecated.
Because "prop" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used.
```

This change replaces the deprecated `pkg_resources` (part of
`setuptools`) with `importlib.metadata` for Python 3.8 and above.

Switching to `importlib.metadata` allows us to drop the test-dependency
on `setuptools` and gets rid of the `DeprecationWarning` raised by
certain versions of `pkg_resources` when being imported:

```
DeprecationWarning: pkg_resources is deprecated as an API
```

Non-integers in these positions would lead to issues when comparing
versions, e.g. `self.version[:2] > (1, 27)`.

In the examples in the MediaWiki documentation, versions are compared
using the `version_compare` function from the PHP standard library:

https://www.mediawiki.org/wiki/Manual:$wgVersion#Example_code

Before comparison, this version canonicalizes version strings according
to the following rules:

- Replace _, - and + with a dot .
- Insert dots . before and after any non number

This commit updates `Site.version_tuple_from_generator` to parse
versions according to those rules.

Replaced the dynamic JSON string construction with a direct dictionary
definition for namespaces.

This commit refactors the codebase to consistently use Python 3.6
f-strings for string concatenation and interpolation.

BREAKING CHANGE: This update increases the minimum required Python
version from 3.5 to 3.6. Python 3.5 reached end-of-life in September
2020 (~4 years ago) and has been dropped from most distributions, so the
impact on users should be minimal.

This commit updates some outdated syntax with the modern alternatives.
The changes were applied automatically using pyupgrade (v2.0.1) with the
following command:

```
pyupgrade --py3-plus **/*.py
```

These updates are purely syntactical and there should be no change in
functionality.

writeapi is being removed

Bug: T294397

Raises an error when ignore=False and the MediaWiki response contains
the `upload.warnings.exists` key. Previously, this warning was logged,
but the call to `Site.upload` succeeded. This could be easily missed by
users, especially when they haven't configured the log level.

As discussed in #197, this renames the `reqs` argument to `Site`
to `connection_options`. The old name still works but triggers a
DeprecationWarning. If you specify both we raise ValueError.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

* simple user creation
* block user
* unblock user
* get basic info about user
* get groups
* add groups
* remove groups
* set groups (get current ones and add/remove what is needed)

* `Iterator.next()`` has been replaced with `Iterator.__next__()`
* The `object.__unicode__()` method is not used anymore
* Default source encoding has changed from ASCII to UTF-8

As discussed upstream in
https://github.com/psf/requests/issues/4564

 , HTTP basic auth
usernames and passwords sent to requests as Python text strings
are encoded as latin1. This of course makes it impossible to
log in with a username or password containing characters not
represented in latin1, as the reporter of #315 found out.

To work around this rather old-fashioned default, let's intercept
string usernames and passwords and encode them as utf-8 before
sending them to requests.

Anyone dealing with a really old server that can't handle utf-8,
or something like that, can encode the username and password
appropriately and provide them as bytestrings.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

This is an alternative approach to solve the problem identified
in #279 . When doing API calls with `retry_on_error` set to
true (the default), if the call fails after all retries are
exhausted, we raise our own `MaximumRetriesExceeded` exception,
which tells you nothing about what actually went wrong, just
that we exhausted the retry count. It seems much more useful
to raise an exception with information about why the connection
is failing.

This changes that behaviour so that, on most paths, we would
raise an appropriate exception from requests (either the one
we caught, or an HTTPError via `raise_for_status`) if we exhaust
the retry count. Only if we fail due to database lag would we
still raise `MaximumRetriesExceeded` (because there isn't really
an underlying exception we can handily raise in that case).

Note that it was already possible to hit
`stream.raise_for_status()` before this change, if the status
code was outside the 500 range, so in theory callers should
already be prepared for that. It was not possible to get a
`requests.exceptions.ConnectionError` or
`requests.exceptions.Timeout` with `retry_on_error` true, though,
so this is genuinely a behaviour change on that front.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

`clientlogin()` does `self.require(1, 27)`, which needs the site
instance's `version` attribute to be set, but this is usually
done by `site_init()`, which is mocked out in the tests. We can
fix the problem by just manually setting a sufficiently high
version in the tests.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

Breaking change: Change the `Site.ask()` method to produce less nested
output. Basically, change `yield {title: answer}` to `yield answer`. The
title is included in the answer object after all.

This fixes tests not being added to the source package.

This reverts commit 1650e0e7.
Upstream restored handling of the adding_headers arg in 0.6.1.
Going back to using that name means we're still compatible with
any version of responses after 0.3.0, except 0.6.0. Also adjust
setup.py to express this correctly.

When there's zero results, the method should not yield an empty
dictionary. Otherwise counting number of results could be wrong (think
`len(list(site.ask('...')))`)

On read protected wikis, we must make sure that we don't include extra
parameters when requesting the login token, or we will get
`readapideniederror`.

- Remove extraneous `continue` parameter from non-query calls
- Remove `userinfo` from `meta=tokens` calls

For MediaWiki >= 1.27, fetch login tokens from the tokens module
using `action=query&meta=tokens`.

Allow sending custom headers (e.g. X-Wikimedia-Debug) with all requests
by passing a dict of header data in the Site constructor.

New implementation of #126

Add OAuth and update docs

- Removing the need to use a double for loop to consume the the result
  by returning a list of revisions rather than a list of pages.
- Parsing the timestamps using the standard parse_timestamp method
- Adding tests

(#84)