Issue 40: Add example test data

[athowes]

Description

This PR closes #40.

I have some remaining uncertainty about:

1. How accessible this data is (internal or external to the package)
2. Should the data be documented?
3. Does the set.seed work as intended? What about that simulate_gillespie() has a set.seed argument?

Checklist

• My PR is based on a package issue and I have explicitly linked it.
• I have included the target issue or issues in the PR title in the for Issue(s) issue-numbers: PR title
• I have read the contribution guidelines.
• I have tested my changes locally.
• I have added or updated unit tests where necessary.
• I have updated the documentation if required.
• My code follows the established coding standards.
• I have added a news item linked to this PR.
• I have reviewed CI checks for this PR and addressed them as far as I am able.

[seabbs]

I think this is fine and a reasonable thing to do but note that CRAN can get funny about including data just for examples. As flagged in the issue we might want to consider the alternative approach epinowcast users or provide some pushback as to why we should take this approach

[athowes]

I've made the test data internal.

As for the seed issue, I've rerun it two times and the results are the same, so seems fine.

[athowes]

I'm pretty indifferent about it being in data/ and accessible or this internal one. I don't know if there are other options.

[athowes]

Have reverted back to data being a part of the package, and added documentation. Ready for review @seabbs.

[athowes]

From https://r-pkgs.org/data.html:

If you want to store R objects and make them available to the user, put them in data/. This is the best place to put example datasets. All the concrete examples above for data in a package and data as a package use this mechanism. See section Section 7.1.

Not perfect fit but arguably the test data could be helpful to a user.

If you want to store R objects for your own use as a developer, put them in R/sysdata.rda. This is the best place to put internal data that your functions need. See section Section 7.2.

The test data are for own use as a developer. It's not "internal data that functions need" though.

If you want to store data in some raw, non-R-specific form and make it available to the user, put it in inst/extdata/. For example, readr and readxl each use this mechanism to provide a collection of delimited files and Excel workbooks, respectively. See section Section 7.3.

No.

If you want to store dynamic data that reflects the internal state of your package within a single R session, use an environment. This technique is not as common or well-known as those above, but can be very useful in specific situations. See section Section 7.4.

No.

If you want to store data persistently across R sessions, such as configuration or user-specific data, use one of the officially sanctioned locations. See section Section 7.5.

No.

[seabbs]

@athowes and I had a f2f chat and concluded we should use simulated data in the tests via test/testthat/setup.R and include the PNAS data for examples / real-world context (with lots of documentation to point back at the original source).

[athowes]

• Added simulated data in test/testthat/setup.R
• Added back ebola data. Got .xlsx direct download from paper in data-raw. Used data-raw/process_raw_data.R to lightly process and save to .rda. Documented data in R/data.R

[seabbs]

This all looks good. A few minor comments

[athowes]

Have fixed these comments I think.

[seabbs]

All good to go now except the minor linting issues

[athowes]

Failing lint due to "Variable and function names should not be longer than 30 characters."

sierra_leone_ebola_outbreak_data change to sierra_leone_ebola_data perhaps.