120 refactor to generate flags in postprocess

[kaitejohnson]

This PR closes #120. It does the following:

• creates a new function that generates a 5 row table of wastewater data flags for each individual model run get_ww_data_flags()
• adds this to the postprocessing pipeline, and saves it in the nested folder structure alongside the input wastewater data and input hospital admissions data (even though these data are joined to the quantiled outputs)
• adds to the _targets_eval_postprocessing.R file to create a combined table of all the wastewater data flags (analogous to _tar_combine())
• this combined wastewater data flags table then gets passed to get_table_sufficient_ww() which was rewritten to summarize this table, returning one boolean on whether the wastewater data is sufficient for each location-forecast_date combination
• removes the loading in of all of the wastewater quantiles, since this was very slow. Instead, we pull in only the quantiles that are needed for generating Figure 2.
• removes the hacky things I added to avoid regenerating wastewater quantiles

@dylanhmorris I still need to test this with an Azure run today, but I think this is generally what we want.

[kaitejohnson]

@dylanhmorris This is the issue I run into when building the container. https://github.com/cdcent/cfa-forecast-renewal-ww/issues/763

I am going to switch back to prod to make sure the issue isn't with this codebase, but is in fact just something with our setup_container.R

[kaitejohnson]

Update I am testing this out now on a few states/forecast dates. Will ensure that it generates the outputs we expect, then will run on all locations. This should make the _targets_eval_postprocessing.R faster to run when outputs change bc it won't require that we load in all the wastewater data and the quantiles to get the dates/locations to exclude

[kaitejohnson]

Confirmed that this generates a dataframe of flags within the nested folder structure for each individual run (just ran on an example few states and dates for now).