manager: fix/change evaluation of ConditionFirstBoot

manager: fix/change evaluation of ConditionFirstBoot

The code to evaluate the kernel command line option was busted because it
was doing 'return b == !!r' at a point where 'r > 0'. Thus we'd return "true"
in both cases:

$ SYSTEMD_PROC_CMDLINE=systemd.condition-first-boot build/systemd-analyze condition 'ConditionFirstBoot=true'
test.service: ConditionFirstBoot=true succeeded.
Conditions succeeded.
$ SYSTEMD_PROC_CMDLINE=systemd.condition-first-boot build/systemd-analyze condition 'ConditionFirstBoot=false'
test.service: ConditionFirstBoot=false succeeded.
Conditions succeeded.

We only use 'ConditionFirstBoot=true' in units, so this wasn't noticed.

But I think the logic is broken in general: the condition should evaluate as
true only during initial boot. If we rerun the units at later points, we should
not consider ConditionFirstBoot to be true.

Also, the first boot logic is also used in pid1 itself. AFAICT, for two
things: in first boot machine-id is initialized transiently (this allows
first-boot operations to be restarted if boot fails), and preset-all is
executed. But this logic was different and separate from the logic to
evaluate ConditionFirstBoot. The distinction is abolished, and the operations
in pid1 now use the same logic as ConditionFirstBoot, which means that the
kernel command line option is checked, and condition_test_first_boot()
just tests whether pid1 thinks we're in first boot.

This makes things easier to grok for the user: there's just one condition for
"first boot" and it applies to both pid1 and units.