Revise strategy api

This MR replaces the former declearn.strategy.Strategy API by a TomlConfig-based FLOptimConfig class implemented under declearn.main.config. It also removes the declearn.strategy module, and moves the existing Aggregator API to the new declearn.aggregator module.

Rationale

The declearn.strategy.Strategy API has until now been a hybrid between a specific API to provide end-users with pre-configured optimization configurations for centralized Federated Learning, and a generic constructor to wrap user-provided objects into an instance that is used to improve the readability of the FederatedServer public signatures and backend code. Since it was first implemented, its revision has been on the to-do list for developers.

This MR adopts the following views:

• The Aggregator API should have its own dedicated module, that highlights its existence and the fact that it constitutes a brick for FL algorithms, just as other components (optimizer, model, etc.).
• The notion that an optimization strategy should be made of a (aggregator, client-side optimizer, server-side optimizer) triplet is rather specific to the centralized federated learning. As such, it should be implemented in the same scope as other centralized FL orchestration tools, rather than presented as its own brick.
• The recently-implemented TOML-based configuration tools ought to enable end-users (or tests and examples developers) to specify the optimization strategy of a FL process using a TOML file (as an alternative to python code).

Changes implemented here

• Remove the declearn.strategy module.
• Add the declearn.aggregator module.
• Add name-based identification and automatic type-registration of Aggregator classes (as done for optimizer plug-ins).
• Implement declearn.main.FLOptimConfig, that replaces declearn.strategy.Strategy.
• Make Vanilla SGD the default for server-side optimization and Averaging the default aggregator.
• Enable specifying client- and server-side optimizers as a single float (the learning rate for vanilla SGD).
• Deploy changes to the examples and tests.
• Update the README and code documentation.

Open questions

• Should we add functions that provide with preset configurations? (e.g. vanilla FedAvg, FedProx, Scaffold...)
• Should we add functions that modify configurations? (e.g. to add Scaffold)
  => at the moment, the previous two points have been left out and will not be part of the 2.0 release
• Should we add a way for end-users to access the list of existing aggregators? (and similarly optimizer plug-ins, etc.)
  => access_types_mapping was added as part of MR !18 (merged), that enables this