Multiple changes, see the body of the discussion thread.

------------------
From Commit 3:
Modified the number of occurrences functionality, so that setting the
number of occurrences will calculate a new ending date. This supersedes
various problems and complexities involved with the previous way that 
number of occurrences was working in the previous commit.

Added a multi function unit test, that tests and demonstrates all the
added functionality.

Fixed a (bug?) wherein previous and next occurrence functions were not
returning anything on excluded dates. Now, the previous and next
occurrence functions will continue searching within the applicable range
until they find an actual occurrence.

------------------
Commit 2 and earlier:

* Consolidated four redundant event "intervals" variables in the event class into a single
variable called RepeatInterval.

* Added Event.EndDateTime to the event class. 
This addition allows the event class to internally define all commonly required event boundary parameters. (instead of most of them.)
Which are: 
1 no start date 
2 fixed start date 
3 no end date 
4 fixed number of occurrences end date 
5 fixed date end date.

* Enforced the event start and end dates on all Schedule class functions.

* Fixed a bug in yearly event builder (which was causing 2 of the yearly
unit tests to previously fail.)

* Added one additional yearly unit test to test the new yearly temporal event
builder code.

* Created overloaded functions for finding the previous and next schedule occurrence,
bounded within a specified date range.

* Fixed unexpected/counterintuitive behavior with a fixed number of event occurrences.
Previously, if you excluded and occurrence date from an event with a fixed number of occurrences,
the last occurrence date would increase in order to keep the fixed number of occurrences constant.
However, in most applications, when the user defines a fixed number of occurrences, they expect that value to translate into a constant end date. Excluding occurrences from this type of event will no longer change the date of the final occurrence, unless the final occurrence itself is excluded. 
In other words, now the final occurrence can decrease into the past, but it can never be pushed into the future.

Concrete example:
I create an event for attending a pottery class. The class will occur once a month, for 12 months. It starts in January, and ends in December.
The March class is canceled. An exclusion is added to the event to account for the canceled class.
The intuitively expected behavior is that now the event will still end in December, and will only have 11 "actual" occurrences. Even though the number of occurrences variable is set to 12. 
Previously, the schedule class would just add another occurrence for the following January... extending the event beyond the previously determined length.
Now, the schedule class will keep the maximum final occurrence date constant. The class will still end in December.

Blake