macro documentation has extra indent

[alexeagle]

python docstrings have to indent paragraphs under a parameter, for example for TypeScript we have this Args: section

https://github.com/bazelbuild/rules_nodejs/blob/ad0e2a4db40f0214ca6fc670d165c15c18de64ee/packages/typescript/internal/ts_project.bzl#L374-L419

The indent underneath each attribute is required to make the docstring syntax comply with the standard and for tools to parse it. In particular we have that line EXPERIMENTAL: generated tsconfig which is not documenting a parameter, it's just some more text in the documentation for tsconfig

When Stardoc produces the protobuf of the docstring the extra indent is still in there.

Note that it works out okay when you render the result in a place that isn't whitespace-sensitive, like in an HTML table. However if you render it in markdown you get a codeblock for each paragraph since leading indent is a markdown syntax for code block.

I think stardoc should de-dent this to canonicalize the doc back to what the author intended, by removing the four spaces from each line after the first in the docstring. so for my tsconfig attribute the proto's docString should be

Label of the tsconfig.json file to use for the compilation
To support "chaining" of more than one extended config, this label could be a target that
provdes <code>TsConfigInfo</code> such as <code>ts_config</code>.

By default, we assume the tsconfig file is named by adding <code>.json</code> to the <code>name</code> attribute.

EXPERIMENTAL: generated tsconfig

Instead of a label, you can pass a dictionary of tsconfig keys.

In this case, a tsconfig.json file will be generated for this compilation, in the following way:
- all top-level keys will be copied by converting the dict to json.
    So <code>tsconfig = {"compilerOptions": {"declaration": True}}</code>
    will result in a generated <code>tsconfig.json</code> with <code>{"compilerOptions": {"declaration": true}}</code>
- each file in srcs will be converted to a relative path in the <code>files</code> section.
- the <code>extends</code> attribute will be converted to a relative path

Note that you can mix and match attributes and compilerOptions properties, so these are equivalent:
...