Add ci to test monitoring scripts

[hannahker]

WIP to address #110.

Some food for thought... would it be worth extending the GMAS_TEST_RUN flag to not call any external APIs? This action could potentially be run quite frequently and I don't love the idea of it making repeated calls to any external systems (could hit rate limits?). What if we stored generated some small dummy datasets that could be the inputs?

I also thought about combining this testing with the existing monitor_{indicator}.yaml scripts, but I like that with this approach we only have to set up the environment once. Open to being convinced otherwise though.

[hannahker]

A couple thoughts:

• Testing the API returns regularly could in theory be a good idea, but I think separate from the work here and potentially redundant. As long as we have checks/validations in the regular monitoring code, I think we'd be relatively well-covered if anything changes in the APIs.
• I was thinking we leave the test variable as it is, but instead update GMAS_TEST_RUN so that it runs things in an entirely self-contained way and avoids all API calls. Logically I think this fits with how we're intending to use this variable. What do you think about that?

[caldwellst]

Okay, clear, I think you're right! I think as long as we have warnings flagging as errors, which we do now in our runs, we are going to be covered. So yes, let's make GMAS_TEST_RUN entirely self-contained. I think what we will need to do is just update all raw_{indicator}.R files to redirect to a sample dataset based on that env var.

Should we have the sample data updating in src-static? Could literally just be like filtering data to 2 countries that we know cover different use cases or visuals (e.g. for IPC, we want Afghanistan because it has subnational analyses, and maybe Burkina Faso because it uses CH data).

[hannahker]

Closing in favour of #131