expand list of permissible types

[maxheld83]

to close #117, among other things, we now only allow DOIs withtype = "journal-article".

There was one DOI already used inside testing (from tu_dois()) which actually violates this: 10.5194/wes-2019-70 (appears to be a preprint).

This has now been removed.

The question arises whether we should/can accept more types at some point.
It seems appropriately defensive to reject all non-"journal-article" DOIs for now, but perhaps there are other types we can work with.

Existing types are:

rcrossref::cr_types()
#> $meta
#> $meta$count
#> [1] 28
#> 
#> 
#> $data
#>                     id               label
#> 1         book-section        Book Section
#> 2            monograph           Monograph
#> 3               report              Report
#> 4          peer-review         Peer Review
#> 5           book-track          Book Track
#> 6      journal-article     Journal Article
#> 7            book-part                Part
#> 8                other               Other
#> 9                 book                Book
#> 10      journal-volume      Journal Volume
#> 11            book-set            Book Set
#> 12     reference-entry     Reference Entry
#> 13 proceedings-article Proceedings Article
#> 14             journal             Journal
#> 15           component           Component
#> 16        book-chapter        Book Chapter
#> 17  proceedings-series  Proceedings Series
#> 18       report-series       Report Series
#> 19         proceedings         Proceedings
#> 20            standard            Standard
#> 21      reference-book      Reference Book
#> 22      posted-content      Posted Content
#> 23       journal-issue       Journal Issue
#> 24        dissertation        Dissertation
#> 25             dataset             Dataset
#> 26         book-series         Book Series
#> 27         edited-book         Edited Book
#> 28     standard-series     Standard Series

^{Created on 2021-03-04 by the reprex package (v1.0.0)}

[maxheld83]

I guess a more fine-grained approach would be to:

1. test whether the fields we absolutely need are given for some DOI (such as container.title whose absence broke container.title does not exist #117)
2. conditionally work around missing fields, if that is recoverable.

Both would be a lot of work and add a lot of complexity, so probably not anytime soon, if ever.

We'd need some sense of how many of the DOIs we even reject b/c of this, and how important that is to our users.

#70 is related.