Update docs

[llrs-roche]

Fix #56

Fixes the documentation issue on #56 with the help of RConsortium/S7#337 (see this comment)
Updates roxygen2 that corrects links to the tools package
Adds myself as a contributor

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 31.04%. Comparing base (9403f40) to head (60a0f8b).

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #55   +/-   ##
=======================================
  Coverage   31.04%   31.04%           
=======================================
  Files          36       36           
  Lines        1601     1601           
=======================================
  Hits          497      497           
  Misses       1104     1104           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[dgkf]

Just for my own knowledge, is this for performance reasons?

Personally, I kinda prefer the type union for transparency. Conceptually, the source code and install resources are quite different and we just happen to be able to use the same syntactic code to evaluate both because of how desc() works. I'm a bit reluctant to convert all of our type unions into symbols in the package namespace because I fear it will be too easy to end up with redundant types (source_code_or_install and install_or_source_code).

If it's for performance reasons, maybe we can wrap this in a local()?

But it's not a strong conviction and happy to hear your thoughts on the right path here.

[llrs-roche]

I was experimenting with new_union() and I moved out this code as I saw it as redunant. I can revert the change as it won't give use big performance gains.

[dgkf]

Suggested change

	source_code_or_install <- new_union(source_code_resource, install_resource)
	source_code_or_install_resource <- new_union(source_code_resource, install_resource)

I know this name gets long, but I think we should be consistent, even if verbose. If we can't be consistent because of the variable length, we should instead find a consistent shorthand, (eg inst_rsrc, src_rsrc, src_or_inst_rsrc). But for critical workflows, I think we should tolerate verbosity to be as clear as possible.

[llrs-roche]

Let's first resolve if we keep it or not, but I don't think adding the suffix makes it too long, so I agree with the suggested change.