ESC: Clean up Integrations Hierarchy

[jkodroff]

We have two types of things intermingled in "Integrations" in the ESC codes:

"Dynamic login credentials", "Dynamic secrets", "Rotated secrets", and the deeply nested pulumi-stacks integration (or are they called providers still?) all make sense to be grouped together. They are special syntax that you use when authoring an Environment. They could be categorized as they are now (probably better?) or flat, but they all go together because they are true, deep integrations.

They could also be grouped with basic syntax if we break those examples out, per #14289.

The rest of the stuff in this section are more akin to examples. They are ways to use basic ESC functionality (like file outputs and the fact you can use ESC with any CLI program) to work with other tools and solve larger problems. These might be better grouped under "Using ESC with..." or something like that.

"GitHub" should be retitled "GitHub Actions" to make it more clear. Maybe even move GitHub Actions to the top level since it's not an example and it's not an integration like e.g. aws-login.

[cleverguy25]

Before we more organized like how you mention. People were not finding the docs. A lot of this organization was learning from the common patterns of how we see our competitors organize, not by type of integration and internal details of how an integration works but by capability.

[jkodroff]

@cleverguy25 What would you think of keeping the reference materials (e.g. aws-login) in one place, and creating a new series of "Using ESC with..." and then AWS/GCP/Docker/K8s, etc.? That keeps us in line with diataxis (which I think is a good way to organize information) while still being end-use oriented.

The "new series" wouldn't be entirely new - we already have what I was imagining with Docker: use case oriented.