Cache results for subject/pipeline

[gcattan]

This PR implements #63. It allows caching the result obtained for a subject in a dataset with a particular pipeline.
The PR also provides a Firebase connector to store and share results online. To enable firebase storing, the credentials must be shared privately between users or stored as a secret in the git repository.

I think it is a nice feature for offline analysis because quantum emulation is really taking a long time. We could also inherit from moabb's WithinSessionEvaluation to enable caching there too. This will make also the example on bi2012 easier to reproduce.

@toncho11, @qbarthelemy FYI

[qbarthelemy]

Ok for me.
But tests must be corrected.

[gcattan]

Thank you @qbarthelemy ! The connection test is failing now because I do not have access to this repository secrets. I can either comment the failing test (firebase will not be available within gh actions) or send you the credentials by mail.

[qbarthelemy]

I've just updated your role, from maintainer to admin.
You should be able to modify gh actions.

[gcattan]

Thank you :) I am updating the secret and re-running the workflow.

[toncho11]

How is Firebase used? To store results?

[gcattan]

Yes! It is used to store result, so we can for example split the work between different computers and gather the results on firebase, and use previous results instead of running another analysis. Here is a basic example from the test file:

    for subject in dataset.subjects_:
        X, y = dataset.get_data(subject)
        pipeline.fit(X, y)
        y_pred = pipeline.predict(X)

        cache.add(subject, y, y_pred)
        score = balanced_accuracy_score(y, y_pred)
        scores[subject] = score

    for subject in dataset.subjects_:
        y, y_pred = cache.get_result(subject)
        score = balanced_accuracy_score(y, y_pred)
        assert score == scores[subject]

The connection test to Firebase is making the pipeline failed. The same secret is used on my repository with no problem (gcattan#13). So I think the workflow is running into an untrusted mode because the base branch is from a fork repository (https://docs.github.com/en/actions/security-guides/encrypted-secrets#using-encrypted-secrets-in-a-workflow). This is why I will comment the connection test for the moment.