If a query returns more than 10,000 records than the following values
are NOT returned:
  x.total_pages
  x.total

Modify the code to allow no value to be set for these values. If there
is not a value returned the functions will now return None.

Update unit test so no longer `xfail`

https://docs.gitlab.com/ee/user/gitlab_com/index.html#pagination-response-headers

Closes #1686

docs: only use type annotations for documentation

A commonly reported issue from users on Gitter is that they get an
AttributeError for an attribute that should be present. This is often
caused due to the fact that they used the `list()` method to retrieve
the object and objects retrieved this way often only have a subset of
the full data.

Add more details in the AttributeError message that explains the
situation to users. This will hopefully allow them to resolve the
issue.

Update the FAQ in the docs to add a section discussing the issue.

Closes #1138

When attempting to add type-hints to the the 'manager' attribute into
a RESTObject derived class it would break things.

This was because our auto-manager creation code would automatically
add the specified annotated manager to the 'manager' attribute. This
breaks things.

Now check in our auto-manager creation if our attribute is called
'manager'. If so we ignore it.

There are small typos in:
- docs/gl_objects/deploy_tokens.rst
- gitlab/base.py
- gitlab/mixins.py
- gitlab/v4/objects/features.py
- gitlab/v4/objects/groups.py
- gitlab/v4/objects/packages.py
- gitlab/v4/objects/projects.py
- gitlab/v4/objects/sidekiq.py
- gitlab/v4/objects/todos.py

Fixes:
- Should read `treatment` rather than `reatment`.
- Should read `transferred` rather than `transfered`.
- Should read `registered` rather than `registred`.
- Should read `occurred` rather than `occured`.
- Should read `overridden` rather than `overriden`.
- Should read `marked` rather than `maked`.
- Should read `instantiate` rather than `instanciate`.
- Should read `function` rather than `fonction`.

Convert our manager usage to be done via type annotations.

Now to define a manager to be used in a RESTObject subclass can simply
do:
      class ExampleClass(CRUDMixin, RESTObject):
          my_manager: MyManager

Any type-annotation that annotates it to be of type *Manager (with the
exception of RESTManager) will cause the manager to be created on the
object.

The 'managers' are dynamically created. This unfortunately means that
we don't have any type-hints for them and so editors which understand
type-hints won't know that they are valid attributes.

 * Add the type-hints for the managers we define.
 * Add a unit test that makes sure that the type-hints and the
   '_managers' attribute are kept in sync with each other.
 * Add unit test that makes sure specified managers in '_managers'
   have a name ending in 'Managers' to keep with current convention.
 * Make RESTObject._managers always present with a default value of
   None.
 * Fix a type-issue revealed now that mypy knows what the type is