Refactor: add a detailed comments structure to config.conf file

[FrancescoDiMuro]

What does this PR do?
This PR introduces a detailed and standardized commenting convention for the config.conf file.
It uses Visual Studio Code’s Better Comments extension to visually distinguish between different types of comments, improving readability and maintainability.

Why are these changes required?
The configuration file previously lacked explanations and a consistent structure for comments, making it harder to quickly identify critical notes versus general documentation.
By introducing categorized comment prefixes (!, *, ?), developers can more efficiently scan the file, understand the purpose of each section, and identify important warnings or references at a glance.

This PR has been tested by: myself

• Unit Tests
• Manual Testing

Follow up

• Ensure team-wide adoption of the commenting convention
• Optionally document the convention in the project README or contribution guidelines
• Eventually adjust explanations for some sections / parameters

Extra details

• ! → Important comments (warnings / required attention, always followed by “Please note”)
• * → Informational comments (context, no action required)
• ? → Reference comments (links, documentation, additional resources)

[lvs0075]

Recommendation: This PR should be split into two separate PRs

1. Documentation-only PR — adds comments exclusively, changes no runtime values, and removes the editor-extension dependency.
2. Config adjustment PR (if warranted) — addresses each parameter change individually with clear justification, reviewed by maintainers on its own merits.

[FrancescoDiMuro]

Recommendation: This PR should be split into two separate PRs

1. Documentation-only PR — adds comments exclusively, changes no runtime values, and removes the editor-extension dependency.
2. Config adjustment PR (if warranted) — addresses each parameter change individually with clear justification, reviewed by maintainers on its own merits.

Thank you for the feedback.
For the first point, I would just explain the concept better by saying that to have a better visualization of the file structure is suggested to have such extension.
What do you think?

To avoid creating a new PR, what do you think if I just restore the original config.conf's original values?
And in this case, I would even remove those that I added and tested.

Thank you again.

[simbadMarino]

I strongly support this PR, having such detailed documentation directly in the config file will significantly improve developer experience while deploying a TRON node (we have received several inquiries around the config file in the past from dev community in telegram).
I agree with @lvs0075, I would recommend to keep this PR as documentation improvement ONLY and avoid changing any config parameter values. I do not see a particular issue with the prefixes as long as we do not push developers into installing a particular editor dependency.

I would recommend to eventually create a similar PR in the Nile testnet repo as well.

Thanks for your support on drafting this PR @FrancescoDiMuro !

[lvs0075]

Recommendation: This PR should be split into two separate PRs

1. Documentation-only PR — adds comments exclusively, changes no runtime values, and removes the editor-extension dependency.
2. Config adjustment PR (if warranted) — addresses each parameter change individually with clear justification, reviewed by maintainers on its own merits.

Thank you for the feedback. For the first point, I would just explain the concept better by saying that to have a better visualization of the file structure is suggested to have such extension. What do you think?

To avoid creating a new PR, what do you think if I just restore the original config.conf's original values? And in this case, I would even remove those that I added and tested.

Thank you again.

Contributors using vim, emacs, IntelliJ, Sublime, and other editors, where those prefixes render as meaningless noise.
Of course, this does not seem to affect the user experience.

Yes, the original values in the configuration file should not be changed in this pull request; if changes are required, please submit a separate pull request.