fix: tolerate a null StandardChangeTemplateName from the server

[susanpann]

Relates to OctopusDeployLabs/terraform-provider-octopusdeploy#574

Changes direction from the original commit. The omitempty tags had no effect — ServiceNowExtensionSettings has a custom MarshalJSON that builds the Values map by hand and never reads struct tags, so the wire format was identical before and after.

Omitting the key isn't the fix either. The server stores Values verbatim and resolves the template with string.IsNullOrWhiteSpace, so an empty string already means "no standard change template". The portal reads Values.StandardChangeTemplateName.trim() unconditionally, so a project written without the key would break the ITSM settings page.

What actually breaks is reading a project whose value is null — UnmarshalJSON asserted straight to a string and panicked with interface conversion: interface {} is nil, not string. Values are now type-checked before assigning.

Three commits:

1. ServiceNow — revert the no-op tags, type-check the four values in UnmarshalJSON.
2. Jira Service Management — identical unchecked assertions, fixed the same way. A JSM project that isn't change controlled skips server-side validation, so a null ServiceDeskProjectName can be stored and panics on read.
3. Test fix — TestJiraServiceManagementExtensionSettingsUnmarshalJSON built its input with ServiceNowExtensionID; nothing asserted the extension ID, so it went unnoticed.

Verified against a local instance for both extensions: a project with a null value panicked before and now reads back as empty, and a create/update/re-read round-trip is accepted and stable.

[tothegills]

Can you describe how this relates to the issue?

[susanpann]

I don't know if it's a required change, but I thought to add the omitempty to mimic what the UI does when sending the request. ie. If the standard template name isn't provided it leaves that field out of the request.