add pluggable loadFormat support for model loaders

[jeremyeder]

fixes #317

Also adds runai_streamer example and tests.

[nerdalert]

@jeremyeder dug around on why this was failing in a deployment. Since the controller only exposes the variables that are present in its TemplateVars struct from modelservice when it renders the preset ConfigMap.

Since .LoadFormat wasn't part of the TemplateVars struct, it will throw the error {{ .LoadFormat }} evaluated to nil and the renderer threw the ,"error":"error executing template: template: template:19:20: executing \"template\" at <.LoadFormat>: can't evaluate field LoadFormat in type in the modelservice pod.

This PR gets things working for me llm-d/llm-d-model-service#221 I didn't test it with the load-format validation yet, just tested that modelservice doesn't blow up on the unknown var which * I think * is all we need to get unblocked.

Can test it with swapping this out in values.yaml which is v0.0.10 patched with the --load-format var:

    # -- Model Service controller image registry
    registry: ghcr.io

    # -- Model Service controller image repository
    repository: nerdalert/llm-d-model-service

    # -- Model Service controller image tag
    tag: "0.0.1"

Will look into CI as well. Not sure how this passes with modelservice crashing in a deployment.

cc/ @sriumcp PTAL and sanity check me here if you get a sec 🙏

[nerdalert]

Model service is disabled in .github/workflows/test.yaml https://github.com/llm-d/llm-d-deployer/blob/main/charts/llm-d/ci/default-values.yaml#L12 so it won't render those configmaps since Helm is skipping modelservice. vllm-sim might be an option and we also have a full e2e on ec2 with https://github.com/llm-d/llm-d-deployer/blob/main/.github/workflows/e2e-aws.yaml (only run on trigger) that I will change to be dispatched on a PR and not just main, that would allow a real e2e that would catch modelservice deployment issues.