Add support for resetting of apps to be imported

[xxthunder]

Description

Added a command line option for scoop import:

• -r, --reset: reset each app of imported JSON after installation

Motivation and Context

I use the import command quite often to define apps and their versions as dependencies in my projects. The reason for this is of course reproducibility of builds. But when different versions from different buckets of an app are already installed, it might still happen that the wrong apps and/or versions are used.
Closes #5525

How Has This Been Tested?

As there are no unit tests available for the changes file (actually there are no functions in scoop-import.ps1) I tested the changes exploratorily with my local scoopfile.json's.
My changes do affect the scoop import feature only.

Checklist:

• I have read the Contributing Guide.
• I have ensured that I am targeting the develop branch.
• I have updated the documentation accordingly.
• I have updated the tests accordingly.
• I have added an entry in the CHANGELOG.

[HUMORCE]

It should not be necessary, because juntion/shims/shorts/etc. of apps is point the latest version when update app.

[xxthunder]

Maybe it should not, but it is. As I described in the issue #5525 if install different versions of the same app, no install or update command gives you what you want.

Example: I have the apps python310 and python311 out of the versions bucket installed. python311 was the last one and so the shim python.exe points to that of python311. If I now import a scoopfile.json refering to python310, nothing is changed during import. I end up with the wrong python.exe in the PATH. Therefore the reset argument.

[HUMORCE]

This happens after both python310 and python311 have been installed already, then the import operation is performed right?

[xxthunder]

Exactly.

[rashil2000]

@xxthunder technically, this is also not required. To see what I mean:

Scoop/lib/install.ps1

Lines 58 to 66 in 6cdcc75

	create_shims $manifest $dir $global $architecture
	create_startmenu_shortcuts $manifest $dir $global $architecture
	install_psmodule $manifest $dir $global
	env_add_path $manifest $dir $global $architecture
	env_set $manifest $dir $global $architecture
	# persist data
	persist_data $manifest $original_dir $persist_dir
	persist_permission $manifest $global

The functions that scoop-reset will run (see below) have already been run by scoop-install (see above).

Scoop/libexec/scoop-reset.ps1

Lines 80 to 87 in 6cdcc75

	create_shims $manifest $dir $global $architecture
	create_startmenu_shortcuts $manifest $dir $global $architecture
	env_add_path $manifest $dir $global $architecture
	env_set $manifest $dir $global $architecture
	# unlink all potential old link before re-persisting
	unlink_persist_data $manifest $original_dir
	persist_data $manifest $original_dir $persist_dir
	persist_permission $manifest $global

[xxthunder]

@rashil2000 @HUMORCE I think this is not true. I want the reset no matter what is already installed. So if I import with, e.g., cmake version 3.24 in my scoopfile.json and cmake 3.24 and 3.26 both already installed and p3.26 was installed the last time. Then the shim cmake points to cmake 3.26. Now I can import my scoopfile as often as I want, nothing will be installed because 3.24 is already installed and nothing will be resetted. So the shim cmake points to cmake 3.26. Exactly this my problem with scoop import. My option --reset solves this.

[rashil2000]

@xxthunder I don't think the update flag is required at all. There are basically three types of apps in the imported scoopfile:

    $app = if ($item.Source -in $bucket_names) {
        "$($item.Source)/$($item.Name)"
    } elseif ($item.Source -eq '<auto-generated>') {
        "$($item.Name)@$($item.Version)"
    } else {
        $item.Source
    }

1. The first case corresponds to apps of the form <bucket>/<app>. When this case is present, always the latest version of it will be installed.
2. The second case corresponds to a fixed/pinned version. Updates should not be carried out in this case.
3. The third case is similar to the second - it points either to a remote URL or a local filepath, where the manifest has a fixed version.

Basically, only those apps, which belong to a particular bucket, are eligible for updates. And this is covered in the (1) scenario (because buckets are always up-to-date, as Scoop follows the rolling release model of updates).

[xxthunder]

@rashil2000 you are right, removed the update flag again. Added two small fixes in import and install. Please have a look when you have time.

[rashil2000]

Check my comment on HUMORCE's thread.