This change adds the beginnings of celery-based tasks for Review Board proper. The stuff that's worth looking at now are: `reviewboard/celery.py`: ----------------------- Setup for core Celery instance. This is used both in the web-server (from `reviewboard.initialize()`) and the worker (via the `worker_init` signal). `reviewboard/tasks.py`: ----------------------- Base definitions for task classes and decorators. This has: * `Task`: The base class for tasks which can run in the "django" context. This provides an API kind of similar to the otherwise too-early-to-use `django-tasks`, where we can use `.using()` to set defaults for how the task is invoked, and `.enqueue()` to actually queue the task (preserving type hinting). This class also handles serialization of Pydantic models for tasks which use it. * `MaybeEagerTask`: A base class that can be used for "core" tasks that may need database access. This allows us to have those tasks run eager in the devserver, but use a worker if available. I will be enhancing this to also check the `task_worker_enabled` setting, so depending on what we end up doing for deployment (and upgrades), existing users can still have any tasks work even without a worker present. * `@task`: A decorator to create tasks that use `Task` as the base class by default, as well as preserve typing on the decorated methods. * `ExternalTask` and `@external_task`: A class and decorator that work similar to `Task` and `@task`, but does not register the task with the celery instance, and uses `celery.send_task()` directly to invoke it. This allows us to decorate a stub function inside the RB code, but have the task implementation live elsewhere (for example, the Review Bot extension would use this, and then the task implementation actually lives in the worker).