Re-work :skip_first_run and :at interaction

[ChaoticBoredom]

As @MarcLapierre pointed out here the skip first run option broke cases where multiple :at were used. This was due to myself not truly understanding how :at worked. It will actually schedule an event for each :at argument, and each of those events would then have :skip_first_run causing it to skip a single first run. W/ a long enough period and short enough restart interval it would cause these events to never run.
The change to make this work properly is to move the :skip_first_run checks from out of the event and into the manager. When the first event is run, it will skip, and then look for any identical events and clear the skip_first_run flag on all of those. So the first event will be skipped, but subsequent events should run perfectly fine.

My apologies for missing the concern, saw the first comment about it breaking the test gem, but then didn't read about the failure of the interaction.

One thought about this, it might be worthwhile to be able to gather these events via some unique ID, instead of relying on users naming their events uniquely.

[pboling]

it might be worthwhile to be able to gather these events via some unique ID, instead of relying on users naming their events uniquely.

Alternatively we could have it raise an error if events with the same name are detected from subsequent definitions, by maintaining a unique registry populated as the DSL is invoked to define the events.

[ChaoticBoredom]

it might be worthwhile to be able to gather these events via some unique ID, instead of relying on users naming their events uniquely.

Alternatively we could have it raise an error if events with the same name are detected from subsequent definitions, by maintaining a unique registry populated as the DSL is invoked to define the events.

Yup, either or works for me. Just wanted to call that out. If it's a big enough issue I can work on fixing that here as well.