implement quick_fix for talawa_good_doc and enforce tab before None of params block

[literalEval]

What kind of change does this PR introduce?

1. Adds quick_fix feature for the talawa_api_doc custom lint rule. Now a template can be inserted with a few clicks to document the code easily.
2. Enforces a tab space before the None of empty param list.
3. Adds URL to Talawa Docs in the error message itself.

Issue Number:

Part of: #1646

Snapshots/Videos:

scr_quick_fix.mp4

[literalEval]

@palisadoes please merge :)
And also, how does the quick fix look ? :)

[github-actions]

Our Pull Request Approval Process

We have these basic policies to make the approval process smoother for our volunteer team.

Testing Your Code

Please make sure your code passes all tests. Our test code coverage system will fail if either of these two conditions occur:

1. The overall code coverage drops below the target threshold of the repository
2. Any file in the pull request has code coverage levels below the repository threshold

The process helps maintain the overall reliability of the code base and is a prerequisite for getting your PR approved. Assigned reviewers regularly review the PR queue and tend to focus on PRs that are passing.

Reviewers

When your PR has been assigned reviewers contact them to get your code reviewed and approved via:

1. comments in this PR or
2. our slack channel

Reviewing Your Code

Your reviewer(s) will have the following roles:

1. arbitrators of future discussions with other contributors about the validity of your changes
2. point of contact for evaluating the validity of your work
3. person who verifies matching issues by others that should be closed.
4. person who gives general guidance in fixing your tests

Other

🎯 Please be considerate of our volunteers' time. Contacting the person who assigned the reviewers is not advised unless they ask for your input. Do not @ the person who did the assignment otherwise.

[palisadoes]

1. This a_line_ending_with_end_punctuation. text will not be meaningful to the user. It doesn't tell them why they should add it. The user needs to understand the rationale so that they can act responsibly when adding documentation.
2. Similarly with the more_info_if_required text. An explanation needs to be given.

This may make sense to you as the developer, but the user will be ignorant of the requirement.

@anwersayeed Please review this PR.

[palisadoes]

Also, does the new auto-inserted text comply with the DartDoc standard?

[literalEval]

Also, does the new auto-inserted text comply with the DartDoc standard?

Yes it does.

[literalEval]

1. This a_line_ending_with_end_punctuation. text will not be meaningful to the user. It doesn't tell them why they should add it. The user needs to understand the rationale so that they can act responsibly when adding documentation.
2. Similarly with the more_info_if_required text. An explanation needs to be given.

This may make sense to you as the developer, but the user will be ignorant of the requirement.

@anwersayeed Please review this PR.

I had thought of it and have provided a descriptive template already (I thought it was descriptive :( ), because the errors generated are quite descriptive, so I thought of being lenient with the template at least.
Can you please suggest replacements for those words ? I'll quickly modify them.

[codecov]

Codecov Report

Merging #1754 (a43c2cd) into develop (2eaae9b) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop    #1754   +/-   ##
========================================
  Coverage    81.37%   81.37%           
========================================
  Files          144      144           
  Lines         7290     7290           
========================================
  Hits          5932     5932           
  Misses        1358     1358           

Impacted Files	Coverage Δ
lib/locator.dart	100.00% <ø> (ø)
lib/main.dart	0.81% <ø> (ø)
lib/models/post/post_model.dart	100.00% <ø> (ø)
lib/services/event_service.dart	33.96% <ø> (ø)
lib/utils/post_queries.dart	100.00% <ø> (ø)
...dels/add_post_view_models/add_post_view_model.dart	94.28% <ø> (ø)
...els/event_view_models/create_event_view_model.dart	100.00% <ø> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[literalEval]

@palisadoes we already have the docs for our lint rules in Talawa-docs. The errors generated are descriptive too. We can also add a file to the codebase which shows all the possibilities of declarations and how to document them.
Moreover, the next step I have planned is to add a link to the corresponding Talawa-docs page in the error messages. So that users can click on them and a very descriptive page opens up for them. I think this much spoonfeeding is good enough even for beginners. We can't do everything.

What is your opinion?

[literalEval]

@palisadoes added URL to Talawa Docs in the error message. Now it will lead directly to the docs page.