Add devcontainer config

[JPrevost]

Why are these changes being introduced:

• Providing a standard development environment will allow for easier
  onboarding and diagnosis of whether an issue is a single local dev
  problem or also a problem in our standard environment

Relevant ticket(s):

• https://mitlibraries.atlassian.net/browse/TCO-89

How does this address that need:

• Adapts the devcontainer approach that new Rails apps provide for TACOS
• Provides some light documentation in the README about alternatives for
  developers that are not using VScode

Document any side effects to this change:

Removes an unused Dockerfile

Accessibility

• ANDI or Wave has been run in accordance to our guide and
  all issues introduced by these changes have been resolved or opened
  as new issues (link to those issues in the Pull Request details above)
• There are no accessibility implications to this change

Documentation

• Project documentation has been updated, and yard output previewed
• No documentation changes are needed

ENV

• All new ENV is documented in README.
• All new ENV has been added to Heroku Pipeline, Staging and Prod.
• ENV has not changed.

Stakeholders

• Stakeholder approval has been confirmed
• Stakeholder approval is not needed

Dependencies and migrations

NO dependencies are updated

NO migrations are included

Reviewer

Code

• I have confirmed that the code works as intended.
• Any CodeClimate issues have been fixed or confirmed as
  added technical debt.

Documentation

• The commit message is clear and follows our guidelines
  (not just this pull request message).
• The documentation has been updated or is unnecessary.
• New dependencies are appropriate or there were no changes.

Testing

• There are appropriate tests covering any new functionality.
• No additional test coverage is required.

[matt-bernhardt]

With the caveat that I'm not super fluent with Docker compose files, I can confirm that the devcontainer defined here works when I'm using VSCode, and I've been able to start it up, run tests and start the server, etc.

The documentation looks good, and addresses my initial confusion about the container being distinct from the server process inside the container.

Given all the above, I'm comfortable approving this - although if you'd rather get an approval from someone more familiar with containers, I understand.

My only remaining question, which is probably addressed by future-us rather than now-us, is whether any of us are intending to work this way at the moment? I'm slightly concerned about a future state where we've added this container for easier onboarding, but it has broken at some point and no one notices because none of us are dogfooding it.

[JPrevost]

@matt-bernhardt Good point re: whether we'll actually use this and nod to maintainabiltiy questions. For context, this is all default for upcoming versions of Ruby on Rails and I just yanked it from a more recent version and popped it into ours. It largely points to external config that is maintained by the community so it should sort of maintain itself. 🤞🏻