V1 forecast evaluation app

[nmdefries]

• Modified run.R to run the targets and then the shiny app, so that shiny inputs (target outputs) are always updated. The idea is to always use Rscript run.R to launch the app. This doesn't prevent the app from being run with old targets output, but would make it a bit inconvenient via requiring the user to manually set forecaster_options (currently set in run.R, not in the app).
• Added a shiny app in ./app.R based off of the flu hosp exploration app. Modified this to only load one forecaster's data at a time and cache the result (up to 1GB memory use total).
• (Dmitry's linting changes got wrapped up in here because of the master -> main switch.)

Notes:

• It remains to be seen how well this performs with forecasts covering longer time periods. Right now, plot rendering, not data-handling, takes the most time, so it seems like we could be handling a fair amount more data without issues.
• Not sure if I did the renv updates correctly, still messing around with that.
• It's technically possible to run the app with old target output. Building an RMD as a target avoids this issue, but isn't as nice for interactively comparing model performance. You have to hard-code a lot of plots to cover the full range of what the app can generate dynamically. An RMD notebook is also faster to use, since all the plots are pre-generated.
• There are some TODOs, e.g. population un/scaling for scores, inclusion of a baseline model as a sanity check (and how to handle if a baseline model is not provided).

[dsweber2]

Running it currently, and it may be a good idea to have it print some statements to the log as it starts, as running ./run.sh, it's very hard to tell what's happening initially, or if it is even running at all. So apparently I should've been looking at run.Rout as well as nohup.out; might want to add a print statement for that to the .sh file.

[dsweber2]

Pretty much exactly what I was hoping this would be, thank you!

Your list of todos makes sense, and some of them are more a problem of adding some forecasters on the other end of the pipeline. Things I would add, all of which are fairly minor details that can probably wait:

• some sort of default plot, probably including whatever we decide is baseline, and possibly the best performing model so far by e.g. WIS.
• the plot is maybe a bit too tall? or maybe not wide enough? Specifically when there's no facets; when it has facets, it's definitely tall enough.
• ideally the facets could have a toggle for whether they all use the same scale, since that is definitely obscuring values in several of these plots

Final thing to think about is the names; with my PR the names are unique, but still not very interpretable. We might want to use tar_read(forecasters) to make saner names somehow (e.g. list the forecaster and some useful subset of the parameters). Maybe a table that lists the scores chosen and their associated parameters, and a lookup thing? Definitely a project for later

[nmdefries]

The app displays data regardless of whether the scores were made this time or not. I thought tar_objects (to get forecaster/output names) would be tied to the current run. Maybe there's a setting to control that. We could also clear the cache every time, but then we wouldn't get speedups from targets.

[nmdefries]

The remaining changes are:

• making forecaster naming clearer. A fix could involve https://github.com/cmu-delphi/exploration-tooling/issues/21
• any baseline normalization
• startup plot (would probably want to include a baseline model)