Celery: use an internal namespace to store build task's data

[humitos]

Use a Task.data (readthedocs.projects.task.builds.TaskData object) to store
all the data the task needs to work instead of storing it directly using
self..

This is to allow us a simpler way to perform a clean before (and/or after)
starting the execution of a new task and avoid potentially sharing state with a
previous task executed that may not be able to perform the cleanup.

The only thing we need to keep in mind is that when modifying these Celery
tasks, we always have to add any new value inside the
self.data.<my-new-attribute> and not directly self.<my-new-attribute> to
avoid this problem. In the future, we could implement this protection at a code
level if we want to avoid this mistake.

See #8815 (comment)
See https://docs.celeryproject.org/en/master/userguide/tasks.html#instantiation

[ericholscher]

This looks like a similar implementation as what was had, and is useful to keep it separate 👍

[agjohnson]

This is a better approach, manipulating __attributes__ probably would have caused a side effect we weren't expecting.

Already discussed, but just archiving here: this does not yet approximate our current pattern, which does use a task-unique instance of TaskStep to encapsulate the task data. We already covered why that pattern isn't usable with the workflow now though. Next up, we will want to turn self.data into a lookup table like self.data[task_id] or similar.