Website: Query API options to preconfigure the GitHub export form

[adamziel]

Description

Adds a custom-paths export type to enable exporting a subset of a directory:

Furthermore, it adds new Query API parameters to preconfigure the GitHub export form:

• gh-ensure-auth: If set to yes, Playground will display a modal to ensure the
  user is authenticated with GitHub before proceeding.
• ghexport-repo-url: The URL of the GitHub repository to export to.
• ghexport-pr-action: The action to take when exporting (create or update).
• ghexport-playground-root: The root directory in the Playground to export from.
• ghexport-repo-root: The root directory in the repository to export to.
• ghexport-content-type: The content type of the export (plugin, theme, wp-content, custom-paths).
• ghexport-plugin: Plugin path. When the content type is plugin, pre-select the plugin to export.
• ghexport-theme: Theme directory name. When the content type is theme, pre-select the theme to export.
• ghexport-path: A path relative to ghexport-playground-root. Can be provided multiple times. When the
  content type is custom-paths, it pre-populates the list of paths to export.
• ghexport-commit-message: The commit message to use when exporting.
• ghexport-allow-include-zip: Whether to offer an option to include a zip file in the GitHub
  export (yes, no). Optional. Defaults to yes.

Related to https://github.com/adamziel/playground-docs-workflow

Testing instructions

• Confirm the GitHub export form continues to work as it did before this PR, that is you're able to export plugins, themes, and the entire wp-content directory as pull requests.
• Go through the Query API options and confirm each does what the description says.
• Attempt exporting two directories in the custom-paths mode.

Also, click here and confirm you're asked to authenticate with GitHub, the doc editing plugin gets installed, and that you can make changes to docs pages and export them to GitHub as a PR.

[dmsnell]

These all seem fine, but they are also adding a set of new options that represents a large percentage of what's already there.

Would be good to see these used first in some documentation, or in a typical workflow setup. Could it make sense to expose this as a JSON object in a similar manner to how the Blueprints themselves are given? I don't think I see that as being better, but I wonder how it compares.

[adamziel]

Thank you @dmsnell! I think you're on to something there – as we've discussed in Wrocław it would be nice to perhaps only have one of these that accepts a Base64-encoded value, just to make these form defaults less distracting. Let's explore that if having many of these attributes leads to a general confusion. Otherwise, I'm going to merge this PR as is to unblock experimenting with the documentation.