Move Kubernetes overlays into the provider schema

[lblackstone]

Problem description

We currently generate API reference docs for several Kubernetes resources using an overlay folder.

It would be more maintainable to generate overlays in the provider schemas under the language section so that the documentation is automatically updated when things change in the provider.

This will involve two parts:

1. Update the overlay handling code to check the schema instead.
2. Update the Kubernetes provider (and possibly the Docker provider) to generate the overlay as part of the schema.

[viveklak]

It would be more maintainable to generate overlays in the provider schemas under the language section so that the documentation is automatically updated when things change in the provider.

As stated elsewhere, the languages section is becoming increasingly messy as it is often where obscure settings land. Does this kind of thing belong in the framework performing the codegen (or document generation) instead? Perhaps if we had a simple visitor pattern with callbacks to perform some pre/post processing, we could achieve the same thing? Just wondering if it makes sense to burden the overall schema machinery with what seem to be very localized issues.

[pulumi-bot]

Cannot close issue without required labels: kind/