Fix comet_ml import and add ensure availability
# What does this PR do?

1. Adds a better check to make sure comet_ml is ready to use
2. Moves the integration imports above the ML imports. This is required to use comet_ml

The current version 3.4.0 is broken, and can not be used with comet_ml without a workaround. This PR fixes that.

## Before submitting
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/master/CONTRIBUTING.md#start-contributing-pull-requests),
      Pull Request section?
- [x] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to the it if that's the case.
- [x] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/master/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/master/docs#writing-source-documentation).
- [x] Did you write any new necessary tests?

## Who can review?

 Trainer: @sgugger

FYI: @stas00 <|||||>> but I agree with @stas00: I wouldn't want to see warnings about cometml or wandb if I don't have the libraries installed.

This is not the case already. We were talking about the odd case where some other package installed one of these as its auto-dependencies. So the user now unwittingly needs to figure out why in the world she needs to get an API key for something she didn't ask for in first place.

Unfortunately I am forced to reset my conda env a lot recently, so I lost the one where this exact scenario has happened, so at the moment I can't point the guilty finger at which package installed `cometml` without me doing so intentionally/directly. If it happens again I will report back.

Otherwise all is good.<|||||>Resolved merge conflicts. Should be ready to go.<|||||>Thanks!