Simplify audit config for the KafkaService

[lmsurpre]

Is your feature request related to a problem? Please describe. for kafka-based notifications, our config block looks like this:

      "enabled": true,
      "topicName": "{{ .Values.notifications.kafka.topicName }}",
      "connectionProperties": {
          "bootstrap.servers": "{{ .Values.notifications.kafka.bootstrapServers }}",
          "sasl.jaas.config": "{{ .Values.notifications.kafka.saslJaasConfig }}",
          "sasl.mechanism": "{{ .Values.notifications.kafka.saslMechanism }}",
          "security.protocol": "{{ .Values.notifications.kafka.securityProtocol }}",
          "ssl.protocol": "{{ .Values.notifications.kafka.sslProtocol }}",
          "ssl.enabled.protocols": "{{ .Values.notifications.kafka.sslEnabledProtocols }}",
          "ssl.endpoint.identification.algorithm": "{{ .Values.notifications.kafka.sslEndpointIdentificationAlgorithm }}"
      }

but for the kafka config in the audit service, we support multiple different ways to configure it:

1. if the load property is set to environment (our current default) then the code looks for an environment variable named EVENT_STREAMS_AUDIT_BINDING

2. if the load property is set to config then we use information from the fhir-server-config instead. it is similar to the notifications config, but uses 'auditTopic' instead of 'topicName'

In our docs, we also list separate properties for kafkaServers and kafkaApiKey in the load=config case, but after inspecting the code I think those are only actually used as a fallback for the load=environment case.

Describe the solution you'd like

1. make load=config the default
2. deprecate the load=environment mechanism
3. remove the kafkaServers and kafkaApiKey properties

Describe alternatives you've considered

Acceptance Criteria

1. GIVEN [a precondition] AND [another precondition] WHEN [test step] AND [test step] THEN [verification step] AND [verification step]

Additional context The load=environment is pretty handy on IBM Cloud, but isn't portable