Reorganize file utils
Author: sgugger
Pull request: yes

# What does this PR do?

This PR reorganizes the gigantic `file_utils` in several submodules, namely:
- `doc_utils` contain all the decorators we use for our docstrings as well as the generic examples
- `file_utils` keep all Hub-related functionality (it might warrant a rename to `hub_utils` see below)
- `generic_utils` contain the "real" utils like custom Enums, to_py_obj etc.
- `import_utils` contains all the `is_xxx_available` as well as the modules that power our lazy inits

To avoid any breaking change, this is all done while reimporting the objects moved into `file_utils`. The only thing that will break is if a user imported a private object from there that has moved, but I think that's okay. The fact all tests pass while no import (except the private objects) was changed (yet) proves it.

The easiest way to review this PR is to just look at the `file_utils` module and look after my comment, where you will find a summary of the functions/classes/constants that were moved in the form of imports. The rest of the diff (apart from the main util files) come from private objects imports, and one import that was incorrect.

I have kept the PR simple for now but will change all the relative imports in every file to take each object from its real source, but before that I wanted to have your opinion on the splits done, as well as the two following points:
- as said above, we could also rename `file_utils` to a more appropriate `hub_utils` (while keeping a `file_utils` for backward compatibility but with just the imports).
- also, the modules I have created could also go in the utils subfolder instead of the root subfolder (and be named `.utils.doc`, `.utils.hub`, `.utils.generic` and `.utils.import` for instance), still with keeping BC.

As soon as we all agree on the move and the names of the new submodules, I will make the changes of import paths in all the files of the lib :-) 

Comments:
_The documentation is not available anymore as the PR was closed or merged._

> also, the modules I have created could also go in the utils subfolder instead of the root subfolder (and be named .utils.doc, .utils.hub, .utils.generic and .utils.import for instance), still with keeping BC.

Related question: we have many files named `xxx_utils.py` outside the `utils` folder. Is it due to legacy files, or is it intentional? 

Thanks a lot for working on this! Very much needed change :-) 

Regarding the two points above:

- I'd be in favor of keep calling the file `file_utils.py` actually as I think it's not **only** related to the Hub. E.g. the name of the model weights is also how they will be called locally "pytorch_model.bin". So don't think it's worth renaming the file here
- I would be in favor of moving everything into a utils folder actually

As per your comments, I've put everything in a `utils` submodule and reimported everything:
- in `file_utils` for backward compatibility (again see all tests passing with no change yet)
- in the `utils` init: this way if we deprecate `file_utils` at some point, the code migration is super easy: replace `from transfomers.file_utils import xxx` by `from transformers.utils import xxx`.

If you agree, I'll clean up all internal imports then merge @patil-suraj @patrickvonplaten @LysandreJik 

> Related question: we have many files named xxx_utils.py outside the utils folder. Is it due to legacy files, or is it intentional?

@gante This is more or less legacy from where the repo was flat and had no subfolders. Some could probably go in the utils subfolder as well, though I'm keeping this PR focused on `file_utils` (it will be big enou already ;-) )