Contributing guidelines for adding input files to /shared

As we develop procedures for contributions, we should add more explicit suggestions for how files should be managed and how we would expect development/review to proceed when new files need to be added for a notebook or module.

Some of this discussion was in comments to #347, where I started to outline where files can be stored and how they will be referenced, but more is needed.

Below are some of the relevant quotes from @jaclyn-taroni

> I think the contributing guidelines need a little more information about how you envision folks will develop material. Where are we supposed to put files? What should we do to get the correct files? https://github.com/AlexsLemonade/training-modules/pull/347#pullrequestreview-594769500

> What's missing for me in here (but I would say it is _implicit_) is what I need to do if I have new files, i.e., when I am working on pathway analysis changes, the single point of truth is `/shared` so that's where I should put them during development and then I add them to `scripts/link-data.sh`. https://github.com/AlexsLemonade/training-modules/pull/347#discussion_r579683159

> How do I get the files I need to perform development? Do I run the scripts/link-data.sh or do I get them from S3? https://github.com/AlexsLemonade/training-modules/pull/347#discussion_r579683454

> Could an interim solution be some suggestions about multiple paths (as in series of steps, not file paths!) one could take depending on the situation? Rather than couch it as "here's exactly what to do." (Might add something about telling reviewers how to test in PRs, too.)

> You may be able to tell that I am imagining a situation where I emerge from a meeting about something else entirely and want to run something I am reviewing myself. 😅

Start by locating the contributing guidelines and reading the cited discussion in #347, along with scripts/link-data.sh. Document how contributors should store and obtain files, when to use the script or S3, and how pull requests should explain development and review steps. Done means the guidance covers the relevant paths without requiring readers to infer the workflow.

Written by the indexing model from the issue text.