[WIP] Non-git mixin

[Wauplin]

Disclaimer: I made quite some mess with the branch/fork so this PR might be temporary one that we close without merging. I created a branch wauplin-non-git-mixin from the main of the main repo and merged the branch non-git-mixin from @LysandreJik's fork. My goal was just to start with a clean state once the merge conflicts were resolved. This PR is quite huge because of the new features from the main branch. To see what huggingface#847 would be after merging see, see the diff comparison (I would rather not start a new PR from this branch to main directly just to avoid losing the previous discussion in huggingface#847).

What is done ?

• resolve conflicts with main
• use upload_folder in both hub and keras mixins
• some docstring

What remains ?
- save pretrained -> signature changes to return List[str] instead of None. Does it impact other subclasses and how ? Document it (see comment).-> done
- adapt tests (and create new ones) -> done
- deprecate previous arguments (repo_path_or_name, repo_url, use_auth_token, git_user, git_email) -> done
- deprecate skip_lfs_files -> introduced in huggingface#858 . For what I understand from this comment, skip_lfs_files is now useless since we do not pull the repo anyway => to be deprecated -> done

How to deprecate arguments ?
I am still wondering what is the policy to deprecate things without breaking changes.

1. In this change, we force the usage of keyword arguments and add the deprecation decorator at the same time. My understanding would be that in this PR/release (0.9 ?) we add the decorator but we still allow it and in next release (0.10 or 0.11 ?) we add the *to force the usage of keyword arguments. Do you confirm ?
2. For argument deprecation, is there a utility decorator I could use same as _deprecate_positional_args ? I didn't find any but maybe you already have this in another repo ?
3. In some cases, I don't see how we can avoid breaking changes.
   a. Will work: use_auth_token. I feel it's fine because we can take the token from either token or use_auth_token and both old and new behaviour work.
   b. Will not always work: repo_path_or_name. What if the user is passing a path to a local directory on its machine ? We cannot handle it with the new behaviour. Does it mean we still need the old implementation with Repository as well and make it live until next release ? I am a bit afraid of "dead code" if we do like this. Any opinion ?

I am also fine with merging this PR to Lysandre's repo and then continue the discussion in huggingface#847

[LysandreJik]

This looks great! Thanks for working on this, @Wauplin.

I think we can merge this and then ask others for review on the original PR.

[HuggingFaceDocBuilderDev]

The documentation is not available anymore as the PR was closed or merged.

[Wauplin]

This looks great! Thanks for working on this, @Wauplin.

I think we can merge this and then ask others for review on the original PR.

Thanks @LysandreJik for the review. I'll fix the few things you highlighted and then merge it to continue the discussion on the "real" PR :)

[LysandreJik]

This looks great, thanks for iterating @Wauplin!