Refactor AWS Deployment

[QuantumManiac]

Rewrote the workflows to deploy Minerva to AWS using AWS's Cloud Development Kit, along with various changes to overall repo configurations to facilitate this new workflow

The proposed new development workflow is as follows:

• Dev creates a feature branch off of main and develops on it
• Whenever Dev wants to test their functionality in a slack environment, they can:
  • Force push their changes to the development branch using the npm run deploy-dev command
• Feature is pushed to development and the changes are deployed to the development minerva
• If deployed successfully and functionality is determined to work correctly, Dev can set up another PR to merge their feature branch to main
• Once PR is approved, feature is merged to main and the changes are deployed to the production minerva

Note that this does not work too well when multiple features are being worked on in parallel, as both would need to merge to development whenever they need to test their functionality in staging, ideally with their feature in isolation from anything else that's also in development. I don't foresee this being too much of an issue because testing deployments are meant to be short-lived so devs would usually not step on each others' feet.

Repo changes that cannot be seen in this PR

• snuck in the renaming of master to main
• added a production and development deploy environment, with each containing the necessary AWS, Google API, and slack keys to deploy minerva to its respective environment. (Note that the AWS access keys are still repo secrets)

Dev documentation for developing minerva will come after this. This will include info on things like

• How to get access to the development slack
• How to gain access to AWS
• The development workflow outlined above
• A brief explanation on how both the dev and prod deploy workflows make use of the same environmental variables through use of deploy environment secrets

I've left comments in the code to help guide and clarify. Please leave questions/feedback as needed

This change is 

[BluCodeGH]

In terms of the branching workflow, I think currently you are trying to combine two fundamentally different models of development and that's what leading to the messy setup.

On the one hand, we want people to be able to have a fast develop/test cycle which means quick merges to develop. Wanting multiple developers being able to work in parallel implies that development needs to be highly transient - where your code is only on it for as long as it takes you to test your feature.

On the other hand, we want to ensure that only working code gets onto master, which means doing a review process for a development->master merge and ensuring it has been well tested on development. That implies code spending a long time on development.

IMO the more important thing here is the fast develop/test cycle, and instead of using branch protection to make sure only good code gets onto master we use the usual review process. So that would make the process:

• Develop on a feature branch.
• When you are ready to test, force push to develop. Use the development slack to test.
• Make changes on your feature branch and repeat if changes are required.
• When you are done with your testing, open a PR from the feature branch to main. It's up to the human reviewers to make sure this code was tested on dev (reviews are free to force push to develop to test themselves) and they can take their time doing code review.