A small but useful improvement: Support for config change packages (auto delete after install)

## Is Your Feature Request Related To A Problem? Please describe.
Yes, for end users which uses Choco and for the package authors:
- **It's great that there are choco "config/settings-packages"** which allows to easily change settings (e.g. [explorer-winconfig](https://community.chocolatey.org/packages/explorer-winconfig))
- But if the end user installs one of the many "config/settings-packages", then it is not intuitive:
he can not just reuse the package again without first uninstalling it (or he has to use `-force`, which is strange for end users, too)
- Therefore, the package authors explain that one should delete or uninstall it after the package was installed, e.g.
> There is no upgrade path for this package. explorer-winconfig is a "one and done" package. It is recommended you uninstall this package after install (settings will NOT revert) so that you can install it again under a different user account if necessary.
(Source: [explorer-winconfig](https://community.chocolatey.org/packages/explorer-winconfig))

### The problem is:
- *Each* "config/settings-package" author must consider for himself how he solves this problem
- *Each* end-user has to figure out for each "config/settings-package" how to work with it: did the Author has solved the issue? Does he expect the user to solve it?
- The third and real problem is that Choco does not offer a solution for this very useful package type, although choco could very easy select and offer a solution 😃

## Describe The Solution. Why is it needed?
### Proposal for the solution
- It would be *very* useful if we could mark packages as a "config/settings-package"
- After `install`, choco would automatically remove those packages
- To mark a package as a "config/settings-package"
or, better: to define the Package-Type to: "config/settings-package",
there are multiple ideas:
- We could use a file similar to `.SkipAutoUninstaller`.
But such solutions are *very ugly* because they are often not documented and the status / behaviour of a package is distributed everywhere: in the .nuspec file, in empty text files, ... and maybe elsewhere.
- Much better would be a configuration property in `xxx.nuspec`:
**This would be great because Cocolatey has a nuspec documentation and tools and even the choco website itself are able to automatically recognize this kind of packages. Therefore, I also propose to replace the `.SkipAutoUninstaller` file by a config setting in `xxx.nuspec`**

#### Therefore, my proposal: add new properties to .nuspec:
```
.nuspec expansion:
• Package type: (if missing: Installer)
• SkipAutoUninstaller: (if missing: false)
• more?
```

### Why is it needed?
- It solves a common and very useful chocolatey use case: Packages which allows to change settings
- It makes Chocolatey much more useful for end users - intuitively!
- Later, tools like Chocolatey GUI could handle this kind of package, too. For example, it does not make sense to spend energy to test if an update is available for those packages.

## Additional Context.
N/A: This issue is just related to the basic coco features

## Related Issues

N/A

The issue names no repository files, tests, or entry points; start by reviewing the proposed .nuspec properties and the existing .SkipAutoUninstaller convention. Clarify package-type semantics, default values, and post-install removal behavior before implementation, including how repeat installation should work.

Written by the indexing model from the issue text.