Initialize repo and add simple memory tests

[d33bs]

This PR adds content to help initialize the repo along with simple examples of testing memory allocation reference counts (where nothing unusual is expected). It builds a scaffold where additional tests and further specification could be provided. As mentioned in the README.md, the work is largely inspired by and may help inform progress for cytomining/CytoTable#75 (in addition to other areas). As a background, I opted for containerized testing of these circumstances to help isolate what I noticed as differences between MacOS Apple Silicon and other OS's when it came to memory management in Python.

Wondering aloud: perhaps the word test is too overloaded and moving to experiment for memory testing would be better?

Thank you in advance for any thoughts and feedback you may have! Please don't hesitate to let me know if you have any questions.

CC @chrisroederucdenver

[d33bs]

Thank you so much @chrisroederucdenver for the review and thoughts! I've added a number of changes to this work based on your comments here and our various discussions. I've moved this to use a test-driven approach within the repo as you suggested (thanks for this, fantastic idea!).

I plan to expand on the existing tests with additional future PR's focused on specific aspects (mostly focusing on building a scaffold / proof-of-concept for now). Mostly this is to limit the scope of additions given the number of possible variables at play (Python version, interpreter version, OS, memory observation tools used, etc).

Your comments also made me feel that further documentation was warranted surrounding memory and how Python manages memory. I've moved this content to CU-DBMI/set-website#28 which will result in a blog post surrounding the topic.

More specific comments:

• Getting started: I added greater documentation surrounding how to get started with concerns to this repo's use of Python.
• More docs on tests: I added some documentation covering this and outlining how test documentation could function for this repo.
• Missing hashbangs: generally these are considered optional for Python, esp. with concerns to packages (they're mostly used in relationship to scripts instead of modules/packages). My own style tends to avoid the use of these as I seek to avoid maintaining an additional line of code per file which may void the practice of DRY.

[d33bs]

Thanks again @chrisroederucdenver, appreciate your thoughts on this throughout! Merging this for now with an eye towards further improvements in the future.