Build different approach for handling options

[francisbarton]

Instead of

boundr::bounds(....., opts = boundr::opts(...))

I wonder if it would be easier for users to think in terms of something like:

boundr::bounds(...) |>
  boundr::boundr_opts(...) |>
  ...

so the options would be a pipeable secondary function rather than a parameter within bounds()/lookup() etc.

This would probably be a thin wrapper around withr::with_options(), but with built-in documentation for the available options.

It could also read in environment variables by default (as fallback values, if a var is found).
This would allow a user to set an envvar for a project (eg with a project .Renviron file) or at the top of a script workflow. For example, "for this whole project I want to work with ESPG 27700 and I am fed up of having to tell boundr this every time." Or "always look for BGC-resolution boundary data".