Create module to keep Standard content up-to-date

[hayfield]

At the moment, the resources module contains a copy of the IATI Standard. Keeping this up-to-date is currently a manual process that requires a new version of pyIATI to be deployed. This is not sustainable.

A long-term solution should allow the content that makes up the IATI Standard (Schemas, Codelists, Rulesets, etc) to be updated without manual intervention.

---

The SSOT cannot be brought in directly using submodules because the structure is not as desired in pyIATI - it contains auxiliary scripts and information that are not desired, while also missing information such as Non-Embedded Codelists. git submodules should also not be used since this adds an additional dependency upon pyIATI that is otherwise not required.

Alongside this, pyIATI is looking to determine a folder structure that could lead to a more sustainable way to manage the IATI Standard. The current train of thought is around using folders rather than branches to track different versions.
There are a few potential issues in this design around maintaining bug fixes across multiple versions (a single fix needs applying to each version, rather than it being possible to apply a single commit to multiple branches). The current branch-based model has, however, become out-of-sync in such as way that these sort of problem that should only exist in a folder-based model are already present.

---

A module should be created that downloads content from the SSOT and updates the local copy of the IATI Standard. This has two major benefits:

• It allows any user of pyIATI to fetch the latest version of the Standard without having to update pyIATI
• It provides an automated method to ensure pyIATI is shipped with the latest version of the Standard when a new version is released

This module (iati.fetch has been proposed) could also be the location for other functionality involving network transfer. This could include tasks such as fetching Datasets from the Registry.

[hayfield]

This is a public writeup of some previous notes on this topic. There are more details and thoughts behind each of the points, though not everything is entirely relevant / adds unnecessary additional complexity.

It was noted in #283 (comment) that this Issue should be created.