feat: narrow the type for 'app' and 'unit' in relation events

[tonyandrewmeyer]

• app is always provided for relation events, except for relation-broken (which may be a Juju bug), so for all of the relation event classes, make the type Application rather than Application|None.
• unit may be provided for relation-changed, and is provided for unit level relation events (joined, departed), but is not provided for application level events (created, broken), so adjust the types in the relation event classes to be either None or Unit as applicable.
• Adjust the tests so that we have a relation-change with and without the unit provided, and so that the app is provided for all cases except relation-broken, which has one test with and one without.

The RelationCreated and RelationBroken classes do now have an odd unit attribute that is defined as always being None, but that was the actual case before and we're just being explicit about it now. I assume dropping the attribute would be too much of a backwards compatibility issue.

Similarly, the __init__ for the various event classes still accept None for app and unit even when they are actually always expected. This is unfortunate, but is stuck for backwards compatibility. Generally, we are the one creating the event objects, not the charmer, so the inexact types in the __init__ shouldn't impact charmers.

Fixes #976

[tonyandrewmeyer]

The grafana-k8s-operator tests assume that emit can be called with just the relation. I think this is an issue with the test, and that couldn't happen in production. However, it still indicates that there are backwards compatibility issues here. So I'll need to do a more minor change that leaves the __init__ in place I suppose.

[benhoyt]

The grafana-k8s-operator tests assume that emit can be called with just the relation. I think this is an issue with the test, and that couldn't happen in production. However, it still indicates that there are backwards compatibility issues here. So I'll need to do a more minor change that leaves the init in place I suppose.

Yeah, I think that assessment is probably right: it's probably too much to change the signature here, even if that test shouldn't really be doing that. So let's leave __init__ alone and focus on the typing changes.