(docs) Clarify how to manage backgroundServiceDisallowedOptions

[AdmiringWorm]

Description Of Changes

• Added a "Common Configuration Options" section explaining how to manage the backgroundServiceDisallowedOptions setting for the Background Service.
• Provided guidance and PowerShell examples for three tasks: unsetting the key, explicitly resetting to the recommended default restricted options, and appending additional restricted options.
• Added a note that appending requires an existing value (get will return empty after an unset), so an explicit set is necessary before appending.

Motivation and Context

• Improve clarity so administrators can safely revert or extend the restricted options used by the Background Service.

Testing

• I have previewed these changes using the Docker Container or another method before submitting this pull request.

Change Types Made

• Minor documentation fix (typos etc.).
• Major documentation change (refactoring, reformatting or adding documentation to existing page).
• New documentation page added.
• The change I have made should have a video added, and I have raised an issue for this.

Change Checklist

• Requires a change to menu structure (top or left-hand side)/
• Menu structure has been updated
• Images added to the img repository?

Related Issue

N/A

[pauby]

There is context here I am missing? Apologies. Without that context, I don't understand this.

[AdmiringWorm]

The context is that the easiest/best way that were found to restrict configurable options where to use them without having a prefix. So for instance instead of --source it would end up just be source for the option that is stored.

There is already logic to prevent the options being specified using the -- before the name of the option.

[pauby]

Suggested change

	Normally there is no need to change the default options that are restricted through the Background Service, and the defaults will be sufficient for most.
	If the default options had been overridden at one point, and there is a need to reset these to the default restricted options, this can be done in two different ways.
	We recommend using the below explicit option.
	The default value for `backgroundServiceDisallowedOptions` will be sufficient for most organizational needs.
	If the configuration has been set, you can reset it to the default value in two different ways. **Note the option we recommend.**

[pauby]

Why is this the recommended way?

If we change the default values in future, we will have to change the docs to match. Would "unsetting" the configuration value not always reset it back to the current default values (when I say current, I mean whatever the default values for the version being used to run the config command is)?

[AdmiringWorm]

I marked this as the recommended way (I don't think it has ever been discussed) due to if someone calls choco config unset then if they in the future do choco config get, the value returned will be empty.

The default values will still be used, it just isn't surfaced to the user if it has been unset.

[pauby]

Is there precedent to using bold headings like this rather than H headings (ie. H3 / 4)?

[AdmiringWorm]

I mainly used bold headings in this PR to be consistent in this file.

The previous PR that I submitted I had also used bold items when there were headers. Mainly because I didn't really consider these headers, but just wanted to emphasize it a bit.

[pauby]

Suggested change

	To be able to add additional restricted options, for instance prohibit the use of the `--force` option, it is needed to include all of the existing restricted options including the options you wish to add to the list.
	It is recommended to get the existing list of restricted options before attempting to set an updated list.
	This can be achieved by using something similar to the below PowerShell example script.
	To be able to add additional restricted options, for instance to prohibit the use of the `--force` option, it is needed to include _all_ the existing restricted options and then add the options you wish to. This can be achieved by using the below PowerShell example code.

[pauby]

Suggested change

	```powershell
	$existingOptions = & choco config get --name="'backgroundServiceDisallowedOptions'" --limit-output
	$updatedOptions = "$existingOptions,f,force" # Add the -f and --force to the existing restricted options variable.
	choco config set --name="'backgroundServiceDisallowedOptions'" --value="'$updatedOptions'"
	```
	<Callout type="info">
	If the configuration value has previously been `unset`, appending the new options in the suggested approach above is not possible as `choco config get` will return the empty value.
	Instead, you will need to be explicit as shown in the _Explicitly set the default restricted options_ example.
	</Callout>
	<Callout type="info">
	If the configuration value is empty, appending the new options using the code below will not work `choco config get` will return the empty value.
	Instead, you will need to be explicit as shown in the _Explicitly set the default restricted options_ example, above.
	</Callout>
	```powershell
	$existingOptions = & choco config get --name="'backgroundServiceDisallowedOptions'" --limit-output
	$updatedOptions = "$existingOptions,f,force" # Add the -f and --force to the existing restricted options variable.
	choco config set --name="'backgroundServiceDisallowedOptions'" --value="'$updatedOptions'"

[pauby]

I think we should look at making this code work for either use case (i.e. if get returns nothing or returns something)?

[AdmiringWorm]

To have it work when get doesn't return anything, that would just be same same as the previous example that set all of the default options (and then append the new options).