logind: ensure seat0 CanGraphical state is written

logind: ensure seat0 CanGraphical state is written

For non-`seat0` seats, attaching a graphics card to a seat can
lead to it getting created. This is because the graphics device
is a "master device" which means that device is a seat-defining
device.

`seat0` may get created, even before the graphics driver is loaded,
though. This is because the graphics driver is loaded
asynchronously at startup, and `seat0` is the primary seat of
system, associated with the system VTs.

When a graphics card is attached to a seat the `CanGraphical`
property on that seat will flip to `true`.

For seats that haven't been created yet (non-`seat0` seats), this
leads to `seat_start` getting called which ultimately causes the
seat to get serialized to `/run/systemd/seats`.

For `seat0`, which is already created, `seat_start` will return
immediately, which means the updated `CanGraphical` state will
never get written to `/run/systemd/seats`.

The end result is that clients querying `sd_seat_can_graphical`
won't get the correct answer for `seat0` in cases where the
graphics device takes a long time to load until some other peice
of seat state is updated.

This commit fixes the problem by calling `seat_save` explicitly
for already running seats at the time a graphics device is
attached.