If a schema is set on a plan, the other schema types are also set

If I set one schema for a ServicePlan (e.g. the Schema for instance creation parameters), the broker's catalog will also contain
the schema keys for the other cases (e.g. instance update and binding creation).
Their Schema's parameters field will then be null, which unfortunately confuses some platforms.

"schemas": {
    "service_instance": {
        "create": {
            "parameters": {
                "$schema": "http://json-schema.org/draft-07/schema",
                "properties": {
                    "foo_prop": {
                        "type": "integer"
                    }
                },
                "title": "instance creation params",
                "type": "object"
            }
        },
        "update": {
            "parameters": null
        }
    },
    "service_binding": {
        "create": {
            "parameters": null
        }
    }
}

vs

"schemas": {
    "service_instance": {
        "create": {
            "parameters": {
                "$schema": "http://json-schema.org/draft-07/schema",
                "properties": {
                    "foo_prop": {
                        "type": "integer"
                    }
                },
                "title": "instance creation params",
                "type": "object"
            }
        }
    }
}

This is because the fields of ServiceSchemas and ServiceInstanceSchema are structs, not pointers to structs.
Originally, they had the json:"omitempty" tag, so I guess the idea was that they should be optional, but that doesn't seem to work with structs in go.

I'm not sure what to do about this without causing a breaking change, though.

Start by inspecting the ServiceSchemas and ServiceInstanceSchema definitions and how their JSON tags affect catalog serialization. Determine how optional schema cases can be omitted without causing an unintended breaking change, then verify that setting one schema no longer emits the other cases with null parameters.