fix: handle tags like debian/2%2.6-21 as identifiers

  * Added type-hints for gitlab/mixins.py
  * Changed use of filter with a lambda expression to
    list-comprehension. mypy was not able to understand the previous
    code. Also list-comprehension is better :)

chore: add type hints to gitlab/base.py:RESTManager

chore: Put assert statements inside 'if TYPE_CHECKING:'

Git refnames are relatively free-form and can contain all sort for
special characters, not just `/` and `#`, see
http://git-scm.com/docs/git-check-ref-format

In particular, Debian's DEP-14 standard for storing packaging in git
repositories mandates the use of the `%` character in tags in some
cases like `debian/2%2.6-21`.

Unfortunately python-gitlab currently only escapes `/` to `%2F` and in
some cases `#` to `%23`. This means that when using the commit API to
retrieve information about the `debian/2%2.6-21` tag only the slash is
escaped before being inserted in the URL path and the `%` is left
untouched, resulting in something like
`/api/v4/projects/123/repository/commits/debian%2F2%2.6-21`. When
urllib3 seees that it detects the invalid `%` escape and then urlencodes
the whole string, resulting in
`/api/v4/projects/123/repository/commits/debian%252F2%252.6-21`, where
the original `/` got escaped twice and produced `%252F`.

To avoid the issue, fully urlencode identifiers and parameters to avoid
the urllib3 auto-escaping in all cases.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

To be safe that we don't assert while running, put the assert
statements, which are used by mypy to check that types are correct,
inside an 'if TYPE_CHECKING:' block.

Also, instead of asserting that the item is a dict, instead assert
that it is not a requests.Response object. Theoretically the JSON
could return as a list or dict, though at this time we are assuming a
dict.

Add some additional type hints to gitlab/base.py

Remove usage of 'import *' in
gitlab/v4/objects/project_access_tokens.py.