Restructure (some) of the markdown to focus around specific configuration issues

[edwbuck]

After the markdown has been transitioned to manually maintained markdown, the manually maintained markdown should be transitioned to highlight specific configuration topics. Proposals for the initial set of configuration topics include:

1. The settings that need to be changed to pull from a local image repository
2. The settings that need to be changed to alter the image name / tags for repackaged SPIRE Servers / SPIRE Agents
3. The settings that need to be altered to specify a specific volume persistence type.
4. The settings that need to be altered to enable / disable / configure Tornjak
5. The settings that need to be altered to enable / disable / configure the Spire Controller Manager
6. The settings that need to be altered to enable / disable / configure a root or child tiered cluster

The goal is not to deliver all of these items in one PR. The goal is to deliver at least one of these items in a PR so we can have an output target for evaluating future generation tools. Unattempted topics should be split into new "future" Issues.

[krishnakv]

Hi Folks, just to add the reasoning behind why this values format i.e. all allowed values with commentary and examples is typically maintained in the default values file.

1. Helm charts are self describing and most operators expect this format
2. A workflow involving cutting and pasting from a README file is messy as YAML is whitespace sensitive - with this default, operators just to have uncomment a few lines and fill in their values
3. Again, most charts have all values in the public interface because users will just skip past or delete the infrequently used options (e.g. tolerations??)
4. The fact that we are using sub-charts to organize - a very good choice given the complexity of what we are trying to accomplish - is an implementation detail and should not dictate the public interface

When initially using the chart, I had to spend quite a bit of time getting into the subp-charts and understanding what has been set and not set as defaults (e.g. the default SPIFFEE ID format), this will greatly reduce adoption esp with people who just want to test out Spire and dig into what all the chart can do. It is a bit more work as we need to make changes in the values.yaml also when changing functionality but JMHO its something we would need to setup before we hit v1.0.

Increasing adoption will also help us with understanding what demand exists for features and what to focus on. Happy to discuss - if there is any other way to achieve this workflow for our users - i.e. examining allowed values and crafting custom values from the command line, we can go with that.

Just to verify the existing best practice/ convention spent sometime going a mix of charts in artifact hub: oci://registry-1.docker.io/bitnamicharts/postgresql, prometheus-community/kube-prometheus-stack, jetstack/cert-manager, argo/argo-cd. They all follow some variation of exposing all allowed values with description/ examples.