Make it impossible to accidentally define a nonfunctional secret extension

[michaeltlombardi]

Summary of the new feature / enhancement

As an extension developer,
I want a clear contract for defining a secret extension that prevents defining a non-functional extension,
so that I can correctly define my extension without reading the implementation code in the DSC engine library.

In the current implementation:

1. The secret.args field for an extension manifest is optional.
2. The secret.args field doesn't require exactly one instance of the name argument (like {"nameArg": "--secret-name"}). This makes it possible to define an extension that can't lookup specific secrets. Presumably, it will always return the same secret regardless of name, which seems counter to the spirit of the secret(<name>[, <vault>]) function.
3. The secret.args field doesn't limit the inclusion of name and vault arguments to a single instance.
4. The process_secret_args function doesn't have any way to pass the secret name to an extension except with the name argument - no handling for if name wasn't processed in args.
5. The implementation doesn't signal to the user that no name can be provided. There's no surfacing of this information either in the representation for dsc extension list or through trace messages.

Proposed technical implementation details (optional)

There are two different paths we can take:

1. Update the JSON Schema to explicitly require args and to require a single name argument and optionally allow a single vault argument.
2. Update the implementation to append the secret name as the final argument to the executable when args isn't defined or is defined without a name argument.

The current implementation allows for non-functional extension manifest definitions. While it could be considered a breaking change to make the schema modifications, since they only exclude non-functional definitions this may be acceptable.