Wikimedia Bugzilla is closed!

The job queue should be able to accept any type of job command, not be limited
to internally-defined commands.  This is necessary because some extensions may
need to modify many articles or perform additional time-consuming activities
after an edit is performed.

There are two issues that need be resolved

1) The ability to define a custom job to run
2) The ability to run a defined custom job

The solution to #1 could be done utilizing the ArticleSave hook.  However, it
might be easier if a new hook was introduced in Article::editUpdates().  (It is
worth noting that the ArticleEditUpdatesDeleteFromRecentchanges hook could be
used for this, but that hook's description has nothing to do with what we are
trying to accomplish).

There are two solutions to #2.  Both involve modifying JobQueue::factory() so
the default: case in the switch block attempts to call a user-defined function.

1) Use a hook to obtain an instance of the Job class suitable to handle a
specified command.  This means creating a skeleton job class and passing it to
the hook and testing to see if the object was re-casted as a different object
type by any hooks that were run.

2) Rely on the __autoload functionality to try to instantiate an instance of a
class named 'Job_$command' or something similar.

#2 is probably the preferred way to do this, at least from an object-oriented
standpoint.