Feat/add syntax autogeneration

[Benni0]

PR Type

What kind of change does this PR introduce?

• Feature
• Bug Fix
• Refactoring (no functional or API changes)
• Documentation Update
• Maintenance (dependency updates, CI, etc.)

Summary

Adds support for custom command syntax auto generation based on command name and parameter definition. If syntax parameter is not provided, the syntax will be generated. The value syntax for each parameter is either derived from the validation type or can be defined by the syntax attribute of the parameter. It's also possible to omit a parameter from the syntax using the syntaxGeneration attribute.

Changes

Added the attributes syntax and syntaxGeneration to the attribute object, and made the syntax attribute on the custom command object optional. Additionally removed the length limit from custom commands syntax attribute, because it might be to low for many use-cases.
Implemented automatic syntax generation and also formatting with line breaks on a soft limit of 150 characters by line in searchbnf.conf.

This is another update after #1977 and #1979.

User experience

Now the user get's automatically a syntax which includes all command parameters and basic value definition. After this change, the developer must only define parameters, where the automatic generated syntax is not sufficient. It is still possible to override the automatic generation by specifying the syntax attribute, so nothing changes for existing projects.

Gerneral notes for syntax in searchbnf.conf:

• The search assistant works well if the value syntax is a predefined type like <bool>, <int> or <string>.
• The search assistant have a weird behavior, if the value syntax is a list of static options, like (high|medium|low), as it shows only the value options, not the parameter.
• The list syntax is not shown in auto completion in the search assistant but it might be helpful as it is listed in the full syntax.
• Escaped quotes in searchbnf.conf seem not to work as documented, as they are not sown anywhere in the search assistant.

The current implementation is based on my experience, which syntax definitions works best for the given scenarios. I'm still not sure if option lists are a good solution, but they are used in many splunk core implementations, so the generator are also using them.

Checklist

If an item doesn't apply to your changes, leave it unchecked.

Review

• self-review - I have performed a self-review of this change according to the development guidelines
• Changes are documented. The documentation is understandable, examples work (more info)
• PR title and description follows the contributing principles
• meeting - I have scheduled a meeting or recorded a demo to explain these changes (if there is a video, put a link below and in the ticket)

Tests

See the testing doc.

• Unit - tests have been added/modified to cover the changes
• Smoke - tests have been added/modified to cover the changes
• UI - tests have been added/modified to cover the changes
• coverage - I have checked the code coverage of my changes (see more)

Demo/meeting:

Reviewers are encouraged to request meetings or demos if any part of the change is unclear