Set git revision at job creation
The proposal in the PR is to add a field `revision` to the jobs, at creation, and it must be non-null (it should be the commit hash).

This way, the job runners don't have to reach the hub to check for the current revision, and we're preparing for (one day) handle multiple revisions in the cache for the same dataset.

Meanwhile, the model is the following:
- we cannot have two jobs for the same dataset but with different revisions: if we create a new job with a new revision, the existing ones are canceled.
- the cache contains the revision in the field "dataset_git_revision", and it's still optional for backward compatibility reasons
- there is no semantics about the time or ordering relation between commits: if we create a job for a given revision, it will be used blindly and replace the cache entries even if this is an older commit.
Set git revision at job creation: The proposal in the PR is to add a field `revision` to the jobs, at creation, and it must be non-null (it should be the commit hash).

This way, the job runners don't have to reach the hub to check for the current revision, and we're preparing for (one day) handle multiple revisions in the cache for the same dataset.

Meanwhile, the model is the following:
- we cannot have two jobs for the same dataset but with different revisions: if we create a new job with a new revision, the existing ones are canceled.
- the cache contains the revision in the field "dataset_git_revision", and it's still optional for backward compatibility reasons
- there is no semantics about the time or ordering relation between commits: if we create a job for a given revision, it will be used blindly and replace the cache entries even if this is an older commit.