Previously was catching AttributeError, which must have been raised
historically for missing `name` attribute on StatusBase subclasses.
This, combined with a `type: ignore` directive concealed that the
`register_status` method does not exist -- the attempt to access it
raises an AttributeError. The correct method is `register`, which
raises a TypeError.

A `type: ignore` directive hid that `status_set` was being called with
the wrong argument types. The intention was to test that an error is
raised on calling with a non-bool argument for `is_app`, however the
status argument should be a string, and was instead a `StatusBase`
class. The test would have still correctly errored out on the `is_app`
argument before this error had an effect at testing time.

_ModelBackend.status_set's status argument was previously type hinted
only as str. However, this argument can really only be one of four valid
statuses that juju's set-status will accept. This commit documents this,
and adjusts the definition of StatusBase to also type hint the six
acceptable status names, as well as using these type hints across code
that interacts with StatusBase and status_set.

Since we know the valid arguments for status, and expose them in type
hints, and since ops already validates arguments here to some extent
(is_app being a bool in status_set, status and message being strings in
Application.status and Unit.status), let's check that status is valid
in status_set and raise a ModelError immediately if not, rather than
catching status-set's exit code and only then raising a ModelError.

Since _ModelBackend.set_status validates its status and is_app
arguments, let's also validate the type of message, removing redundant
checks from Application.status and cleaning up a fixme in Unit.status.
Also add a test to cover this, analogous to the existing test for the
type of is_app.

Since StatusBase.from_name is part of the public API, and is currently
used in several charms, changing the type of the name argument from str
to _StatusName will break users' tests. Furthermore, satisfying the type
checker as to the contents of the strings used may be painful for users,
leading to a proliferation of casts or `type: ignore`s. Therefore, the
type or the name argument has been reverted to str.

Unclear how to narrow type of value given that type checking doesn't
excellently support properties with differing types for getter and
setter, so sticking with a simple `cast` for now.

Either work, as we're just testing that the type not being bool or str
raises an error, but bare object may raise eyebrows for readers.

InvalidStatusError is a subclass of ModelError, so it shouldn't break
any user code, and anyway it doesn't look like people were setting
invalid statuses since Juju would give them an error at runtime
currently.

Calling add_status with an ErrorStatus *will* eventually result in
an InvalidStatusError. Calling add_status with an UnknownStatus *may*
eventually result in an InvalidStatusError.

The plan is to make using ErrorStatus and UnknownStatus here an error