`unitOption` is only used inside of `attrsOf` wich is perfectly capable of
handling the attrsets from `mkIf`, though the checkUnitConfig test
forbids it. This commit weakens that restriction to allow the usage of
`mkIf` inside of `systemd.services.<name>.serviceConfig.<something>`
etc.

@thelegy writes:

  unitOption is only used inside of attrsOf wich is perfectly capable of
  handling the attrsets from mkIf, though the checkUnitConfig test
  forbids it.

  This commit weakens that restriction to allow the usage of mkIf inside
  of systemd.services.<name>.serviceConfig.<something> etc.

While I personally don't like that we can't easily use
pushDownProperties from the module system and need to rely on internals,
we *already* use internals for the mkOverride case, so adding another
case for mkIf doesn't add a hard-to-find indirection.

I'm merging this, since this fixes a valid use case and it shouldn't
make refactoring worse than before.