Module to list arguments to salt modules without loading

[mchugh19]

What does this PR do?

This is a rewrite of the baredoc module first merged in #52044 and to be merged into master in #54570

The original baredoc used regex parsing to find functions and attributes. This PR rewrites baredoc to use python ast as a less brittle parser.

There are occasional use-cases for listing state functions. It might not be common, but in order to generate autocomplete listings for vscode, I needed to know what possible state functions might exist. I tried installing a bunch of dependencies and run on linux and windows to use sys.list_state_functions. That was pretty good, but probably missed lots of states which won't load due to dependencies.

The reasoning for baredoc's existence was listed as:

It is sometimes helpful to know all the execution and state module functions that exist. The Salt loader and sys.doc go a long way to providing that, but are unable to return modules and functions that do not have current dependencies installed. This execution module does some primitive parsing on all the .py files in the modules and states directories and returns a dictionary keyed by module and function name. Each dictionary entry contains a list of arguments that the function can take.

What issues does this PR fix or reference?

Possibly superseeds: #54570

New Behavior

Provides a listing of salt execution and state modules functions and default arguments by reading files from the filesystem rather than having to local code requiring dependencies. Support custom modules (anything synced with saltutil.sync_{states,modules} as well as func_alias

Merge requirements satisfied?

[NOTICE] Bug fixes or features added to Salt require tests.

• Docs
• Changelog
• Tests written/updated

Commits signed with GPG?

No

[s0undt3ch]

Awesome approach!

Just found a nitpick on a comment.

[s0undt3ch]

Windows test failures are related and look problematic.

[mchugh19]

The windows failures seems to be with saltutils.sync* functions, which should not be impacted by the addition of this module. I am also unable to replicate the errors locally. Any thoughts?

[mchugh19]

all tests for master currently appear to be dependent on #56700