Migrating existing Contributor Guide to wiki-style format

[m-miedema]

Addresses #57 and references #49

Should be merged after #56

This PR breaks up our existing Contributor Guide into a wiki-style resource. It also introduces some new sections of the guide to lay the groundwork for both re-tooling some of the content that exists and adding new content in future PRs.

Proposed Changes

• Adds a new Contributor Guide top-level tab to the website
• Adds corresponding pages to generate the outline
• Migrates existing Contributor Guide and related-resources to new pages
• Removes outdated information from these resources (e.g. Gitter links)
• Added small new section of text to Recognizing Contributions page

Change Type

• bugfix
• refactoring
• infrastructure
• documentation
• other

Checklist before review

• I added everything I wanted to add to this PR.
• [Documentation only] I built the docs locally.
• My contribution is harmonious with the rest of the code: I'm not introducing repetitions.
• My code respects the adopted style, especially linting conventions.
• The title of this PR is explanatory on its own, enough to be understood as part of a changelog.
• I added or indicated the right labels.

• I added information regarding the timeline of completion for this PR.

• Please, comment on my PR while it's a draft and give me feedback on the development!

[m-miedema]

The main thing I haven't found at least a semi-reasonable home for in the previous contributor's guide is this section:

Aims of physiopy

physiopy is a very young project developed by a bunch of
researchers from the two different sides of the Atlantic Ocean (for
now). Our main goal is to help collect, analyse and share physiological
data, interfacing with (MRI) neuroimaging. We're trying to do so by:

1. Writing packages to make a user-friendly pipeline to deal with
   physiological data.
2. Writing packages that take into account the use of this
   physiological data in combination with neuroimaging (MRI) analysis.
3. Providing documentation containing tips and strategies on how to
   collect such data and use our packages.
4. Help set a standard for these data, albeit without forcing users to
   use it.
5. Be an excuse for educational purposes on topics like Git/GitHub,
   Python3, physiology and related tools/topics.

Is it still relevant to put somewhere else in the website, or have we pretty much covered it at this point?

[goodalse2019]

Thanks Mary! This all looks great to me. I went through all comments and didn't find anything to change. If we are ready, happy to merge.