Return custom input binding errors through KRM results instead of panicking

[snguyen64]

Problem

In pkg/function v0.2.2, errors returned while finalizing a custom input binding are propagated out of the internal main function and then converted to a panic by the public function.Main entrypoint.

The relevant flow is:

1. readInputStruct calls input.Finalize().
2. If Finalize() returns an error, readInputStruct returns that error directly.
3. The internal main only serializes ErrInputReadingFailed; other input errors are returned.
4. Public Main panics with error while calling synthesizer function: ....

This differs from errors returned by the synthesizer function itself, which are added to the KRM ResourceList.results with error severity and written to stdout.

For custom input bindings, validation and parsing errors are expected runtime input failures. Turning them into process panics makes the synthesis look like an unexpected crash, bypasses the normal KRM error result contract, and makes structured error reporting harder for callers.

Expected behavior

Errors from custom input binding/finalization should be serialized as error-severity KRM results and written through the OutputWriter, consistent with synthesizer-function errors. function.Main should reserve panics for framework initialization failures or genuinely unexpected conditions.

Reproduction

Register a custom input type whose binding function returns an error:

function.AddCustomInputType(func(secret *corev1.Secret) (*Config, error) {
    return nil, errors.New("invalid config")
})

When that input is finalized, the process panics with:

panic: error while calling synthesizer function: invalid config

Expected output is a KRM result equivalent to:

results:
- severity: error
  message: invalid config

Malformed or invalid custom-input data should therefore be observable as an ordinary synthesis failure rather than a synthesizer crash.