[chore][docs] Reflect current practices about configuration structs i…

…n coding guidelines (#11549)

<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description

<!-- Issue number if applicable -->

Reflects existing practice in coding guidelines.

#### Link to tracking issue

Relates to #6767, fixes #9428

docs/coding-guidelines.md

@@ -38,6 +38,15 @@ To keep naming patterns consistent across the project, naming patterns are enfor
   - `func CreateTracesExport(...) {...}`
   - `func CreateTracesToTracesFunc(...) {...}`
 
+#### Configuration structs
+
+When naming configuration structs, use the following guidelines:
+
+- Separate the configuration set by end users in their YAML configuration from the configuration set by developers in the code into different structs.
+- Use the `Config` suffix for configuration structs that have end user configuration (i.e. that set in their YAML configuration). For example, `configgrpc.ClientConfig` ends in `Config` since it contains end user configuration.
+- Use the `Settings` suffix for configuration structs that are set by developers in the code. For example, `component.TelemetrySettings` ends in `Settings` since it is set by developers in the code.
+- Avoid redundant prefixes that are already implied by the package name. For example, use`configgrpc.ClientConfig` instead of `configgrpc.GRPCClientConfig`.
+
 ### Enumerations
 
 To keep naming patterns consistent across the project, enumeration patterns are enforced to make intent clear: