Refactor datatype festival

[giplt]

The datatype festival could be a lot easier once the datatype event (#131) is implemented.

[matthijskooijman]

Such an "event" page type, when used as part of a festival, should probably not get its own url in the root namespace (like normal pages), but instead only exist "inside" the festival page (where the festival page is responsible for routing requests to the event and/or processes requests itself). This still allows getting a list of all "event" pages if you query recursively.

    <page id="5cf806dfd2661" type="festivalpage">                              
      <language id="en" name="festival2019"/>                                  
      <page id="5cf806dfd2661" type="event"/>                                  
    </page>

Then the festival page XML will refer to the event page id for each contribution.

Having separate page XML for contribution events would probably simplify translation and versioning for events as well (#335).

To allow customizing display or derive attributes for certain kinds of events, a "subtype" approach might be useful, where there is e.g. a festival_contribution_event or agenda_event which is a subclass of event and can override some methods (and maybe also add subtype-specific methods and fields). Such a subtype could just be the type="..." value in the hypha.xml, but that would somewhat complicate querying "give me all events" (though with some reflection, getting a list of all datatypes that extend the event base type is certainly possible). Maybe adding a subtype (or something implements="event") could make querying easier (but that does essentially duplicate the PHP class inheritance info in the XML).

Open question: Where to store the extra data? E.g. "Notes for the organizers" is not an event property, but only exists for festival contributions. Do we store that in the festival XML, along with the reference to the event page id? Or inside the event page XML as an "extra" attribute/tag (i.e. not interpreted by code that looks at any event, but interpreted by the festival module)? Storing it inside the event XML could help to include the property in the translation / versioning structure (though for this particular "notes for the organizers", this would not need to be translated, maybe only versioned).

[giplt]

I would put the extra field(s) in the festival XML as they apply specifically to the context of the festival and need no translation.