Allow detecting whether service https is unset

[jvstme]

Make the https service configuration property
Optional. This allows to determine whether the
property was omitted or explicitly set by the
user. In a future version, we could use that to
improve validation or change the default on the
server. For now, the behavior is unchanged - an
unset https is equivalent to https: true.

Backwards compatibility is preserved for the most
part, except two side effects:

• Users may see a phantom https change in the
  run plan when redeploying a service after
  upgrading to CLI 0.20.12+. This, however, will
  not block the rolling deployment and will not
  cause any actual changes to the service
  behavior.
• Users with a pre-0.20.12 CLI will not be able to
  trigger a rolling deployment on a service
  deployed with a 0.20.12+ CLI and will see the
  Failed to apply plan. Resource has been changed
  error message.

[peterschmidt85]

Tested this on a live server with two gateways (private + public). The https: None handling works well — old CLI (0.20.11) can read services with null https fine.

One thing I noticed: old CLIs crash when listing services that have https: "auto" (from #3600), since the old bool type can't parse the string. The compat layer here handles None but not "auto".

Should we also exclude https from old client responses when it's "auto", same as we do for None? Or is it fine to leave it — auto is a new feature anyway and old CLIs wouldn't know what to do with it.

[peterschmidt85]

Tested with both the new CLI (from this branch) and old CLI (0.20.11) against this branch's server. New CLI handles https: null and https: auto correctly. Old CLI can list, get, apply, and force-redeploy services that have https: null — no errors. See my comment above re https: "auto" compat.