collect_*_status and lifecycle events

[PietroPasotti]

logically, collect_status is a lifecycle event, aka framework event, since it's not 'custom' in the way user-defined events are, and it is emitted by the framework on itself whether the user wants it or not, quite like commit/pre-commit.

At the moment we log their emission as custom event which is somewhat misleading and complicates jhack tail's life when attempting to distinguish them from 'true' custom events.

I propose we make CollectStatusEvent a LifecycleEvent subclass, and we uniformly start logging all LifecycleEvents so jhack tail can pick them up if the user wants to see them (but they will be hidden by default as they are generally speaking not interesting and would clutter the output).

[PietroPasotti]

see #1080 for an implementation proposal

only doubt I have is whether that is 'too much logging', as it's basically three lines we're adding to each charm execution for (most of the time) no true value.

I doubt whether knowing about pre-commit/commit will ever be valuable (unless, like some actually do, the charm relies on them for control flow!, but then they can log it themselves.)
However knowing about collect-status, I expect, will be more interesting.

[PietroPasotti]

Could also considering special-casing collect status events and only logging them, skipping other lifecycle events.