Fix scheduler data structures

[bethlakshmi]

Our data for the scheduler makes me crazy - it's the legacy of our team's old disagreements and misunderstandings of how this data needs to work.

For the most part, I've papered over it for the users - although the UI is still lacking in this area. I'd assert the UI problems are separate - it's more a matter of me not knowing how to do truly spiffy stuff like drag and drop calendar GUIs.

But what IS affected is doing even minor things - like #330. Adding an extension to the self-description of an object (an event) shouldn't require me to re-learn the nuances of object inheritance in python and the various odd ways that I had already threaded through the describe() and str() functions.

Spec'ing out the work I'd like to do here:

Right now we have:

scheduler.event - the specific time, place, and people for a schedule booking, also max volunteers, if approval is needed, and other behavior characteristics scheduler.eventitem - the abstract un-schedule related data - truly there's very little here, it's a hook for scheduler to have something abstract to chain to the scheduler.event booking. It has the quality "visible" to keep a booking off our public calendars. It's not an abstract class, though, it's a real database table. gbe.event - the real center of the data that is unrelated to when an event happens. Title, description, conference, default room gbe.Show, gbe.Class, gbe.GenericEvent - actual instantiations of gbe.Event. There's truly very little data here. Shows have a cue-sheet (what do we even use this for???), GenericEvent has a "type" (Volunteer Spot, Special Event, Master Class, Rehearsal Slot) because none of these types involve any other special data, there just needed to be a switch to change certain behaviors, and then Class is the weirdo - because it ALSO inherits from Bids, it has duplicate data for title, description, conference, and it has a "bidder" - which is the most useful part, since that becomes the default teacher.

What I want to do:

1 - flatten as much data as possible - create 1 central "Event" that has both the booking related data and the independant-of-booking data, because really having a separate copy of title, description, etc for each time/place the event happens is totally fine (and more intuitive to anyone using it).

2 - offer a unlinked pointer to stuff that is GBE related, namely:

• the bid in the case of class
• for default room and teacher, this could be a default resource(s) that are kept at the event level, but that link through down to the gbe level of specific inventories of room/teacher
• the "type" would be a value kept at the schedule level, but what "types" we support would be controlled by the GBE level. (more coming, but need to save)

[bethlakshmi]

Some more stuff:

• remove cue_sheet from the data storage - that is the only thing that is special about a Show...
• do we ever use the "notes" field in Event?