Introductory material to understand how the workflow operates andits terminology and concepts in the software development domaincompared to generic project managed.Includes a schedule.Also add a reference guide.

The Commitfest Workflow is a formalization and extension of the existingcommitfest-only protocol.  There is now some in-app documentation and theidea of moving patches to the "next CF" has begun being deprecated. Insteadthe UI provides the user valid choices on where to transition patches,which, with the introduction of the Drafts commitfest, is basically oneor the other.  Committers gain the ability to transition patches intoIn Progress if desired.  Patches within In Progress commitfests canbe moved into either Open or Drafts.  Begin enforcement of a maximumof one commifest in each of  Parked, Open, and In Progress.The workflow defines the drafts commitfest as lasting for one yearmatching up with the major release process.  Namely, once thecommifest leading up to feature freeze is In Progress a newDrafts commitfest should be created.With the workflow changes it is necessary for CFBot to be made awareof the specific commitfest ids that are active.  Provide a JSON APIfor this purpose to begin weaning CFBot off scraping html.The workflow in-app documentation includes a month-based scheduleshowing which commifests are active, and their names, in each month(among other related details).  Begin enforcing the existing rulethat future commitfests cannot have patches via triggers.  Futurework on the administrative and UX aspects of the CFApp likely willdo away with future commitfests altogether.  Thoughts on the topicare welcome in the GitHub issues.