Clarify vote counting in the code style template

What does this MR do?

When reading the original I found "the votes" ambiguous - I wasn't sure if it's only maintainers' votes or all votes.

Proceed with the proposal once 50% of the maintainers have weighed in, and 80% of the votes are 👍

I think we can improve this situation by clarifying this sentence.

The current MR implements Option A.

Option A - we count only upvotes from maintainers

This commit highlights the fact that we only count maintainers' upvotes.

diff --git a/.gitlab/issue_templates/Coding style proposal.md b/.gitlab/issue_templates/Coding style proposal.md
index a969c9b72ee..95f0fb5f366 100644
--- a/.gitlab/issue_templates/Coding style proposal.md
+++ b/.gitlab/issue_templates/Coding style proposal.md
@@ -5,7 +5,7 @@ Please describe the proposal and add a link to the source (for example, http://w
 -->

 - [ ] Mention the proposal in the next backend weekly call and the #backend channel to encourage contribution
-- [ ] Proceed with the proposal once 50% of the maintainers have weighed in, and 80% of the votes are :+1:
+- [ ] Proceed with the proposal once 50% of the maintainers have weighed in, and 80% of their votes are :+1:
 - [ ] Once approved, mention it again in the next backend weekly call and the #backend channel

Option B - we count all upvotes

This commit highlights the fact that we count all upvotes.

diff --git a/.gitlab/issue_templates/Coding style proposal.md b/.gitlab/issue_templates/Coding style proposal.md
index a969c9b72ee..95f0fb5f366 100644
--- a/.gitlab/issue_templates/Coding style proposal.md
+++ b/.gitlab/issue_templates/Coding style proposal.md
@@ -5,7 +5,7 @@ Please describe the proposal and add a link to the source (for example, http://w
 -->

 - [ ] Mention the proposal in the next backend weekly call and the #backend channel to encourage contribution
-- [ ] Proceed with the proposal once 50% of the maintainers have weighed in, and 80% of the votes are :+1:
+- [ ] Proceed with the proposal once 50% of the maintainers have weighed in, and 80% of all votes are :+1:
 - [ ] Once approved, mention it again in the next backend weekly call and the #backend channel

Does this MR meet the acceptance criteria?

Conformity

• [-] Changelog entry
• Documentation (if required)
• [-] Code review guidelines
• [-] Merge request performance guidelines
• Style guides
• [-] Database guides
• [-] Separation of EE specific content

Availability and Testing

• [-] Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• [-] Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• [-] Security reports checked/validated by a reviewer from the AppSec team