Moving from https://github.com/bazelbuild/bazel/tree/3d2604806a9747f317c5b560bbf89cdc1be033ba

* src/main/java/com/google/devtools/build/skydoc/renderer/RendererOptions.java and src/main/java/com/google/devtools/build/skydoc/renderer/RendererMain.java have been changed to use JCommander instead of Bazel's options library for command-line arg parsing. All other .java files have been copied from Bazel without any changes and without any file/directory renames.
* integration tests from src/test/java/com/google/devtools/build/skydoc/testdata in Bazel have been merged into tests/testdata in Stardoc where appropriate (filter_rules_test, function_basic_test, function_wrap_multiple_lines_test, multi_level_namespace_test_with_allowlist, provider_basic_test, pure_markdown_template_test, repo_rules_test)
* updated Stardoc's deps and to allow building the renderer. In particular, we now are forced to depend on rules_jvm_external unconditionally, even in releases.
* removed renderer_binary.jar

…ocity for templating (#163)

Internal tooling complains about any new Velocity usage

Reverts #133 so that HTML escaping is not applied to Markdown. Instead, Markdown content such as docstrings can use HTML formatting and escape angle brackets with backslashes, HTML entities or inline code segments. Default values are embedded in inline code segments instead of `<code>` tags, which does not require escaping.

As a result, docstrings behave just like regular Markdown contexts while default values are rendered without smart quotes and can contain both `<` and `` ` `` without causing escaping issues.

Also includes tests based on #138.

Fixes #137
Closes #138
Fixes #142
Closes #143

Requires bazelbuild/bazel#18867

Co-authored-by: Adam Azarchs <adam.azarchs@10xgenomics.com>

…lable

* When available (i.e. in Bazel 7, or in current development Bazel at HEAD), try use the `starlark_doc_extract` native rule for doc extraction instead of the legacy pre-built extraction jar. This behavior can be disabled by passing `use_starlark_doc_extract = False` to the `stardoc` macro.
* Add templates and markdown rendering functionality for repository rule and module extension info protos (which are output by `starlark_doc_extract`).
    * Temporary wart: for module extensions, by default we would want the summary blurb to look something like
```
my_ext = use_extension("@my_local_repo//some:file.bzl", "my_ext")
my_ext.tag(foo, bar)
```
but alas, we don't have a good way to get the name of the local repo from Starlark when bzlmod is enabled.
* ... and of course, update tests. Which means in some cases, we have to fork the golden files into current (i.e. `starlark_doc_extract`-enabled) and legacy flavors.

Fixes #69
Fixes #76
Fixes #81
Fixes #123

… apply it properly (#167)

In Markdown table cells, apply HTML escaping only to code blocks, and apply it properly

Since #161 removed HTML escaping for defaults and function docstrings, we should do the same for attribute and param docs in table cells.

The only limitations Markdown places on table cells are:
* no pipe characters (they must be escaped with a backslash)
* no newlines (they must be transformed into `<br>` or an HTML entity)

The latter restriction makes it impossible to have a fenced code block inside a table cell.

Therefore:
* we do not escape HTML or Markdown markup outside a fenced code block
* we keep existing logic for escaping newlines outside a fenced code block
* we fix fence detection (e.g. allowing more than 3 fence characters to support embedded code blocks in code blocks, allowing tildes as fence characters, properly handling language names, etc.);
* in code block content, we escape HTML, and we escape newlines as HTML entities (since `<br>` does not work in a `<pre><code>` block) - finally fixing code block newlines in table cells.
    
This is a followup to #161.

Partially addresses #118

Most Stardoc users are probably documenting their rules for users from other repos - so we ought to render labels in the repo being documented with the repo name.

We want bazelbuild/bazel@b71b2df in order to dedent and trim doc strings from all sources (not just functions, but also rules, providers, attributes, etc.).

Since we are building the renderer from source and using rules_jvm_external to pull in Maven deps, the WORKSPACE setup for a user of Stardoc is now significantly more complicated; the user will now need to do the multi-step rules_jvm_external initialization and maven_install.

For convenience, let's wrap maven_install in a macro - and finally split out the legacy-test-only maven deps into their own .json file and repo.

Update stardoc_repositories to pull in all the new deps we need to build Java code.

Update maintainer guide.

…supported (#171)