Refactor project state management

[lorenzo-cavazzi]

Description

Moving ProjectModel to the global redux store and the functions to ProjectCoordinator requires a gradual approach.
The idea is to first migrate the code used in single tabs (Files, Collaboration ...) to either ProjectCoordinator or a dedicated coordinator wherever this makes sense (e.g. this is already the case for Interactive Environments and it may be the case for datasets #1182).
The safest approach may involve temporarily storing the data in 2 positions at the same time.
An example is fetchCommits, that requires "metadata.id". That is still fetched by the fetchProject function in ProjectModel, but the content is also saved to the global store in the container fetchProject function using the new projectCoordinator.
Once nothing references the ProjectModel content anymore, the need for duplication will go away and it's only a matter of cleaning up the unnecessary invocations.

Notice that, in this fetchProject example, the schema in the global store is different. The idea is to keep the fetching + fetched variables approach to know if the current information status. That is already extensively used in other parts in the global store.

To be effective, we should try to store all the content coming from an API in a separate object, and avoid nesting when unnecessary.
In the following case (taken from here)[https://github.com/SwissDataScienceCenter/renku-ui/blob/aa7b63d12f4042b92e73d5064fc8b4fdeab9766f/client/src/model/RenkuModels.js#L257-L286], commits and metadata both have fetched and fetching variables. The structure is slightly different, but the behavior is similar. We expect that checking those variables would give us a clear indication of the status of the related data.

projectGlobalSchema {
  commits: {
    list: object[],
    fetched: Date nullable,
    fetching: bool,
    error: object nullable
  },
  metadata: {
    fetched: Date nullable,
    fetching: bool,
    exists: bool,
    id: string,
    otherProp1: <...>,
    otherProp2: <...>,
    <...>
  }
}

Nesting commits in metadata would be a bad idea because it wouldn't be clear which control variables I should check to assess the status, nor if refreshing the parent metdata object would reset also the commits.

Steps

This is the plan to refactor the Project state management:

• Move Collaboration tab content (due to Lift issues and merge requests state to root #624 , this may require only to duplicate shared content and provide it through the projectCoordinator)
• Move data and functions used only by Datasets tab (check first Move DatasetListModel to global store #1182)
• Move data and functions used only by Files tab
• Move any remaining Overview tabs content
• Remove ProjectModel and move all the remaining functions to the project coordinator (no need for duplication anymore)