Refactor Tracker logic and write guards for logging_dir

[muellerzr]

Refactor logging_dir logic and make better guards for trackers that need one

What does this add?

This PR refactors much of the logic when it comes to how Trackers are initialized and checked inside of Accelerate

Who is it for?

• Users of Accelerate who want to use W&B, TensorBoard, etc and want clear errors as to what went wrong

Why is it needed?

I noticed that users were finding it confusing as to why a logging_dir must always be passed in when using "all", and this was because of TensorBoard requiring a logging directory.

On top of this, the current logic to check if a tracker can be added is a heap of spaghetti code that isn't maintainable.

What parts of the API does this impact?

User-facing:

When users forget to pass in a logging_dir to Accelerate.__init__ and a particular tracker needs them, an error is now raised stating:

Logging with `TensorBoardTracker` requires a `logging_dir` to be passed in.

Internal structure:

Each GeneralTracker implementation now requires that the requires_logging_directory be set, as this is a foundational method for checking whether logging_dir should be passed. As a result this is an abstract property, not a default (as the user should know explicitly).

There also now exists a LOGGER_TYPE_TO_CLASS dictionary to severely reduce the boilerplate code needed in Accelerator.init_trackers when it comes to checking if a logging_dir argument is needed

[HuggingFaceDocBuilderDev]

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

[sgugger]

Thanks for fixing! The logic for all the logging in the init of Accelerator is starting to take a lot of code, so I think we should refactor it in a separate method to keep the init cleam.

[sgugger]

Very nice!

[muellerzr]

@sgugger pinging for a rereview just to make sure the refactor seems sound to you 😄

[sgugger]

LGTM, thanks for refactoring the bit that gets all loggers outside of the Accelerator!

[sgugger]

Much cleaner!