1. If a value is of type ArrayAttribute then append '[]' to the name
   of the value for query parameters (`params`).

This is step 3 in a series of steps of our goal to add full
support for the GitLab API data types[1]:
  * array
  * hash
  * array of hashes

Step one was: commit 5127b1594c00c7364e9af15e42d2e2f2d909449b
Step two was: commit a57334f1930752c70ea15847a39324fa94042460

Fixes: #1698

[1] https://docs.gitlab.com/ee/api/#encoding-api-parameters-of-array-and-hash-types

Commit b6447211754e126f64e12fc735ad74fe557b7fb4 inadvertently
introduced a possible breaking change as it added a new argument
`iterator` and added it in between existing (potentially positional) arguments.

This moves the `iterator` argument to the end of the argument list and
requires it to be a keyword-only argument.

* feat(downloads): allow streaming downloads access to response iterator

Allow access to the underlying response iterator when downloading in
streaming mode by specifying `iterator=True`.

Update type annotations to support this change.

* docs(api-docs): add iterator example to artifact download

Document the usage of the `iterator=True` option when downloading
artifacts

* test(packages): add tests for streaming downloads

There is no reason to return an `int` as we can always return a `str`
version of the `int`

Change `EncodedId` to always return an `EncodedId`. This removes the
need to have `mypy` ignore the error raised.

Create a custom `warnings.warn` wrapper that will walk the stack trace
to find the first frame outside of the `gitlab/` path to print the
warning against. This will make it easier for users to find where in
their code the error is generated from

utils.EncodedId() has basically the same functionalityy of using
utils._url_encode(). So remove utils._url_encode() as we don't need
it.