Add documentation about how to handle closely related packages

[joelnitta]

Some packages are designed to work well together, or one package may not have any use at all without the other (e.g., {targets} and {tarchetypes}). There should be formal guidance on how to treat such packages during code review (under what circumstances should they be included in a single review vs. split, etc.)

cf ropensci/software-review#401

[maelle]

we'd need guidance for the author guide (I'd probably recommend opening a pre-submission inquiry to help figure things out on a case by case basis) and the reviewer guide. Also maybe the editor guide (how exactly do you recruit reviewers for a probably more complex + time-consuming review process).

[maelle]

We'd also need to check how the infrastructure would handle this (cc @mpadge)

[maelle]

this comment ropensci/mregions2#17 (comment) by @salvafern reminded me of this