Added framework for WNTR extensions

[kaklise]

Summary

The following PR adds a framework for WNTR extensions. WNTR extensions are intended to house beta and self-contained functionality that adds to WNTR, but is currently not part of core WNTR development. The extensions should be designed for a wide audience. This PR include a very simple "Hello World" example extension that uses the intended file structure. More information is included in the Contributing section of the WNTR documentation.

Tests and documentation

The hello world extension includes a simple test and documentation. The Contributing section of the documentation was updated to document the file structure for extension source code, documentation, and testing.

Acknowledgement

By contributing to this software project, I acknowledge that I have reviewed the software quality assurance guidelines and that my contributions are submitted under the Revised BSD License.

[coveralls]

coverage: 85.755% (+4.2%) from 81.528%
when pulling a9e6e97 on kaklise:extensions
into 387cce4 on USEPA:main.

[kbonney]

Overall, the design is clean and the separation of extensions from core is well thought out. The file structure conventions are documented clearly and the example "hello_world" extensions provides a good example for developers working on extensions.

Several minor issues need to be resolved before merging:

• We need to decide and document how extensions should handle additional requirements.
• Syntax error in coverage run --source=wntr --omit=$OMIT -m pytest -m "not time_consuming" -m "not extensions" --doctest-modules --doctest-glob="*.rst" wntr, duplicate -m flags override rather than combine.
• Any doctests added by an extension's documentation will run along with core WNTR. I assume we don't want this to be the case so we should add --ignore=wntr/extensions to the pytest invocations in our CI/CD for core WNTR.

The latter two points are simple fixes that I can address. The first point may require some discussion. Two potential options are to specify extras_require options for each extension in setup.py or to have a requirements.txt file in each extensions src folder.

[kbonney]

We will move forward with the extras_require approach to extension dependencies. As part of this approach, I added an update to move requirements.txt optional, test, and documentation dependencies to extras_require fields. I also added some draft text in the developer docs about requirements.