Improve the TOC DD Guide regarding projects not ready, address adopter interviewing

[TheFoxAtWork]

In the course of Due Diligence, if the TOC member finds issues with the project, like lack of sufficient adopters, or not meeting criteria, the following clarity needs added to the TOC DD-guide.

Current text: If some of the criteria are not yet met, or missing, the TOC member triaging will add a comment detailing all items that are unmet or missing and close the application; affixing the "not-ready" label and move the card to the "Not-Ready-Will Return" column of the TOC project board's Applications to Move levels tab. Projects are expected to re-apply upon completion of outstanding items. When the project is ready to reapply, they should link to the previous application so the TOC may leverage and reuse as much prior work as reasonable.

Needs modified to include:

For small issues, like insufficient number of adopters with expected implementation or self-assessment, TOC members will grant the project 2 weeks to resolve the issue to keep the application and Due Diligence moving forward. For larger issues, or if the project is unable to resolve the issue in 2 weeks, the TOC member will close the application with the current progress on due diligence either as a comment on the issue, or as a closed PR (depending on progress) linked to the application issue.

For adopter interviews, the TOC adopter interview template should be modified to include the following at the beginning of the request (before the anonymity information):

The intent of these interviews is to ascertain the experience and value CNCF projects have provided to their adopters is solving meaningful problems. This means your organization has adopted the project directly, is currently utilizing it in a near-production or production capacity in the manner it was intended and can provide feedback about how the project has provided your organization with measurable value in addressing or delivering a technical solution. If your adoption of the project does not reflect the above, please let us know so we may update our records. For more information on what constitutes and adopter, please refer to our FAQs.

Direct adopters of a project are responsible for the project's development, packaging, configuration, or deployment in their use of it. Transitive adopters of a project are not responsible for the project's development, packaging, configuration, or deployment, however they may receive the benefits that the project provides. In the case of the example above, the Service Provider's use of Kubernetes enables their customers to use Knative, which relies on Kubernetes as part of its architecture. However, if the Service Provider's implementation enables their customers to develop, package, configure, or deploy Kubernetes as part of the Knative offering, those customers are then also direct adopters.

We also need both application templates updated to specify:

Adopters submitted for interview must have a current implementation of the project in at least dev/int/staging and at least one adopter must have the project in production for incubation level. Graduated projects must have majority of adopters interviewed with production deployments. The adopters provided for interview must be able to explain the value of integrating the project to solve their specific problem (i.e. automating their application feature delivery to desired users of mobile applications with seamless roll back) and not in a manner that resells the open source project to an adopter-by-proxy (i.e. Marketplace provides instances of open source projects where the marketplace is the adopter submitted for interview..