Improve run_tutorial()

[gadenbuie]

Brings a few new features to run_tutorial():

• Allow name to take a path to local tutorial directory. The name must be an existing directory and package must be NULL. Since run_tutorial() manages the tutorial directory and uses the dir argument of rmarkdown::run(), we pre-emptively thorw an error if there is more than one .Rmd in the directory and none are named index.Rmd.

• Add arg clean to run_tutorial(), cleanly re-render the tutorial when TRUE. We follow the same logic used in validating the tutorial directory to identify the tutorial .Rmd file, since rmarkdown::shiny_prerendered_clean() requires a specific file rather than a directory.

• Launch tutorial in viewer pane by default, if possible. It's not currently possible to open tutorials in the tutorial pane interactively, but by giving launch.browser a function, we have a place to modify this in the future.

Fixes #600
Fixes #333

[rossellhayes]

Looks good to me, just a small typo!

[gadenbuie]

Update: I also added support, turned on by default, for running a tutorial as a background RStudio job. The tutorial opens wherever shiny apps open by default, using the shiny.launch.browser option.

In theory, we could also open the tutorial in the Tutorials pane, but since there isn't a public API for stopping Rstudio jobs, we'd end up having to build too much infrastructure to achieve parity with the built in tutorial running methods. That's another reason why I decided not to go further; the RStudio tutorial pane depends on run_tutorial() and I'd prefer to avoid a cyclical dependency. The new default for run_tutorial() is to use an RStudio job, but it can be disabled by setting as_rstudio_job = FALSE and it, by default, won't try to run as a job in non-interactive environments (like other RStudio jobs).

[schloerke]

Minor changes.

• Remove multi-Rmd-file logic warning in available_tutorials_for_package()
• Add Breaking Change news item about shiny_args now being after ...

Otherwise LGTM!

[gadenbuie]

I'm glad I let this sit for a little bit. Coming back to look at it again, I think the restriction that name be a directory when referring to a local file feels too arbitrary.

I stuck with the directory approach because we move the tutorial directory to a temporary location if we don't have write access where the tutorial is stored. That logic makes sense when the tutorial is hosted in an R package, which may be stored in a location that's inaccessible to the end user. But it doesn't make sense for a local file.

I'm going to update the PR to accept a specific file in name. If a file path is provided but the directory isn't writeable, we'll throw an error rather than copy the directory.

[rossellhayes]

This looks good, I just caught a few typos and one potential small improvement