docs: add new documentation related to testing style guide and testing template

[EshaanAgg]

Summary

Adds

• Style guide for testing
• A test template and common ways to use the mocks

References

Slack Discussion

Reviewer guidance

---

Testing checklist

• [ ] Contributor has fully tested the PR manually
• [ ] If there are any front-end changes, before/after screenshots are included
• [ ] Critical user journeys are covered by Gherkin stories
• [ ] Critical and brittle code paths are covered by unit tests

PR process

• [ ] PR has the correct target branch and milestone
• [ ] PR has 'needs review' or 'work-in-progress' label
• [ ] If PR is ready for review, a reviewer has been added. (Don't use 'Assignees')
• [ ] If this is an important user-facing change, PR or related issue has a 'changelog' label
• [ ] If this includes an internal dependency change, a link to the diff is provided

Reviewer checklist

• Automated test coverage is satisfactory
• PR is fully functional
• PR has been tested for accessibility regressions
• External dependency files were updated if necessary (yarn and pip)
• Documentation is updated
• Contributor is in AUTHORS.md

[github-actions[bot]]

Build Artifacts

Asset type	Download link
PEX file	kolibri-.pex
Windows Installer (EXE)	kolibri-0.16.2b1.dev0+git.1101.g7eb2f443-windows-setup-unsigned.exe
Debian Package	kolibri_0.16.2b1.dev0+git.1101.g7eb2f443-0ubuntu1_all.deb
Mac Installer (DMG)	kolibri-0.16.2b1.dev0+git.1101.g7eb2f443-0.4.1.dmg
Android Package (APK)	kolibri-0.16.2b1.dev0+git.1101.g7eb2f443-0.1.2-debug.apk
TAR file	kolibri-0.16.2b1.dev0+git.1101.g7eb2f443.tar.gz
WHL file	kolibri-0.16.2b1.dev0+git.1101.g7eb2f443-py2.py3-none-any.whl

[EshaanAgg]

Thanks, @MisRob and @AlexVelezLl, for all the help. I have updated the documentation as per the review comments. I also took the liberty to make two more changes:

• Remove the imports for VueRouter from each of the sample tests and templates, as the same should be fixed by #12105
• As discussed in a review comment of #12056, it is better that while mocking composables we pass the composable related mocking data in a separate property to the render function. I have updated that recommendation too.

Let me know if you would like to see something else added!