Quality guidelines for samples

[bart-vmware]

As we're updating samples for Steeltoe v4, please keep the following guidelines in mind:

• Start from the standard .NET 8 project templates, add comments for Steeltoe/sample-specific changes.
  • Suffix project names with "Web" for web-based clients, suffix with "~Service~Api" for APIs and microservices (applies only when multiple apps interact).
  • Don't delete parts from the standard project templates that aren't strictly needed for the sample. The goal is for readers to recognize the boilerplate code. Removing parts raises the question of whether the sample is incompatible with the boilerplate.
• Consider adding non-web-based projects, such as WorkerService/Desktop/Blazor where it makes sense.
• Enable nullable reference types and prefer modern C# syntax, such as records and primary constructors.
• All samples should have the Steeltoe.Samples.[AppName] code namespace prefix, in subdirectory [AppName] (do not repeat the category, such as connectors/management/discovery/etc).
• In manifest.yml, app name should end with "-sample", service should start with sample, so any running orphaned instances in CF are easy to recognize.
• Consider adding integration tests, if feasible, and add status badges to /README.md.
• Consider adding random-route: true to manifest files.
• Run code-cleanup (you can sync style settings from Steeltoe using /tools/sync-DotSettings/sync-DotSettings.ps1).
• Don't forget to describe how to use the sample in a README.md.

Bonus points:

• Use modern features, such as minimal APIs

[bart-vmware]

Pending alignments:

• ~Connector and~ Discovery samples don't use the Steeltoe.Samples namespace prefix, app/service name in manifest.yml doesn't follow naming guidelines.
• Security samples don't use the project name suffixes, #333.