This PR effectively rewrites the operator/ codebase. Over the past few weeks, I have been looking into refactoring the codebase to both simplify it dramatically, given its new reduced requirements, and allow it to be structured in a way that allows us to evolve our installation strategy. Namely, an increasingly converging behavior with Helm, migration paths to helm, etc. I have spent considerable time attempting to refactor the codebase to do so, and what I have ultimately concluded is that the way the codebase is currently structured is (somewhat subtly, at first glance) extremely problematic.

Aside from usual issues around tech debt and an organically evolving codebase, both of which impact the codebase heavily, there is a systemic issues in how data flows through the system. We have a variety of critical objects:

• IstioOperator with values/meshConfig as a Struct
• Values translated to a Values, MeshConfig translated to a MeshConfig
• All of the above translated to map[string]any
• All of the above translated to structpb.Struct
• All of the above translated to JSON
• All of the above translated to YAML

Through a simple install, we transition between these states an incredible amount of times. In one case, we wanted to translate to an IstioOperatorSpec into an IstioOperator; to do so, we converted to yaml, to a map, back to yaml, then to a Go template, then unmarshalled back into an IstioOperator. While that case is clearly an easy fix, there are many other cases where the structure of the codebase requires us to do constantly move back and forth.

My original attempts at cleaning up the codebase were to simply cleanup the discrepancies with values and meshConfig not being typed. I did two different prototypes of this, one keeping IstioOperator as a proto and another one just using standard Go structs. Both of these were not able to be completed. The root of the problem is we are really inherintly dealing with unstructured data. Most of the codebase is doing things like "merge these two maps", "set values.foo.bar=1", etc -- these are extremely hard to do with structured data. We currently do this with a custom-made library, tpath, which is incredibly complicated to handle all the edge cases of the structured data. Many times we avoid this by translating between various type formats (as discussed above), but this introduces even more complexity, as we have all these alternative paths to manipulate data.

This PR instead treats a map[string]any as the core data structure, wrapped in a values.Map type. Not-coincidentally, this is also how the Helm codebase is structured (originally, I had directly used most of Helm's libraries. However, for backwards compatibility we have different --set semantics unfortunately).

Beyond that, we now have clearly devised installation phases:

• Merge all inputs into a single unified configuration
• For each component, render the chart. Explicitly apply postprocessing steps (overlays) independently
• for manifest generate: print and exit.
• for install: apply to the cluster.

This structure should be more conducive to future feature work. For instance, if we want to perform a helm migration tooling, we can easily insert logic after the 'merge all inputs'.

Overall, the intent of this PR is to have no user facing behavioral changes, with two minor exceptions:

• istioctl manifest generate --component - filters to one component. Can already be done by just only enabling that component, does not exist on istioctl install
• istioctl manifest generate -o <dir> - output files to a dir instead of a file. It hasn't worked since at least 1.18, so I am pretty confident there is no usage

These were excluded just to clean up the code mostly

Fixes #52469