adds a ServiceAccount attribute to the MCPServer CRD

[ChrisJBurns]

As part of #654, we want to be able to create dedicated ServiceAccount's for MCP servers instead of sharing the ToolHive ProxyRunner ServiceAccount. This PR adds the serviceAccount attribute to the MCPServer CRD and bumps the CRD Helm Chart version.

The idea is that if a ServiceAccount name is given in the MCPServer CR, ToolHive Operator will create the MCP Server pods to use it. Otherwise if the field is omitted from the MCPServer CR, the ToolHive Operator will create the ServiceAccount automatically.

Changes Breakdown

• ServiceAccount CRD attribute addition
• Additional RBAC resource logic that creates the ServiceAccount if not specified in the CR, or to use it if it is specified
• The podTemplateSpec generation logic has been refactored. Instead of directly producing the patch sent to the ProxyRunner via the --k8s-pod-patch flag, we now use a dedicated MCPServerPodTemplateSpecBuilder. This builder uses .With[FieldName] methods to construct the template spec dynamically, allowing for more complex configurations in the future. The change also makes testing easier, podTemplateSpec creation can now be validated directly through the mcpserver_podtemplatespec_builder_test.go unit tests, rather than indirectly via higher-level stack functions.
• Added the serviceAccount test expectations to the Chainsaw E2E tests.

Ref: #654

[jhrozek]

awesome, this will make e.g. the vault integration much more streamlined