refactor: notifying emails to people in thread

[ayush00git]

Closes #100
Closes #97
References - #101

This PR deploys the people in thread method to complete the email workflow for a post's lifetime. Much more reliable then then the current email workflow in the app.

Updates -

1. As a post is created, append user's email and the corresponding XEN's email to the PeopleInThread slice.
2. As any other admin type interacts with the post, it could be any comment / status change add his email as well to the PeopleInThread slice.
3. Comment APIs like FacultyPostComment should also trigger the email workflow.

Design choices -

1. Keep the old email sending workflow intact, just for steam lining the very first post update email sent to the xen.
2. On post creation the appending is handled by the go-rountine.
3. Ignore the mail for the person who just interacted. i.e. don't send the mail to the user itself who commented.

[ayush00git]

Problem - we need a data structure similar to a set here, []string would store multiple duplicate emails and send them multiple notifications as well.

Since the maximum number of people that could be in a post are just 5 (author, xen, ae, 2 jes), so we could just create a helper method - appendUnique an corollary to append() method of slice in go.