Add mypy.ini, mypy-zope-plugin

[H-Shay]

This PR adds a mypy.ini file, and specifies modules which are missing type support to be ignored. It also adds the mypy-zope plugin, and fixes a mypy error in utils/emailutils per this convo: #355 (comment)

signed off by H-Shay, shaysquared@gmail.com

[H-Shay]

I see that I have to rebase this once 355 is merged and force push it as there are commits from 355 in here-this is because I based it on a branch that has not been merged, correct?

[H-Shay]

hopefully this is good to go!

[callahad]

It would also be great if you could make a final commit in here with git commit --signoff to automatically add in the Signed-off-by: ... line to the commit message

[callahad]

Looks good to me! So sorry for the pedantry, but one final change to request: could you please split the changes to sydent/util/emailutils.py into their own pull request, so this one's changelog can just be about adding mypy configuration?

[callahad]

...and a few other comments

[H-Shay]

Question re: this comment: #357 (comment)
I cherrypicked the commit in question and added it to a new branch, then opened a PR on that new branch. As far as this branch is concerned, does it makes sense to
a. wait until the new PR is approved and update this branch once it is (which I am assuming will cause a merge conflict which could be easily resolved) or
b. try and revert the commit in question (using the hash/id) so it is no longer on this branch, and then updating this PR?
Option 'a' seems a little saner but not sure of what is best practice...

[callahad]

Let's go with reverting e618512 here

[callahad]

For small PRs, or ones that haven't been reviewed yet, it's common to use git rebase --interactive origin/main to replay all of the commits on origin/main but with the option of re-ordering them, skipping some, editing others, etc. But once it's been reviewed, rebasing can make it more challenging to know what's changed since the last review, etc.

[callahad]

Otherwise, consider this 👍 once that revert happens :)