Deprecate and neuter MunkiCatalogBuilder processor; update MunkiImporter processor

[gregneagle]

This PR implements some changes discussed today in the #autopkg channel in MacAdmins Slack today. Namely, it deprecates and neuters the old, mostly abandoned MunkiCatalogBuilder processor. This processor was used in only two publicly shared recipes, and repo containing those recipes is being archived.

With this change, running a recipe containing a MunkiCatalogBuilder step results in a deprecation warning and no action is performed for that step:

autopkg run Test.munki -v
Looking for Test.munki...
Found Test.munki in recipe map
**load_recipe time: 0.0009514169942121953
Processing Test.munki...
WARNING: Test.munki is missing trust info and FAIL_RECIPES_WITHOUT_TRUST_INFO is not set. Proceeding...
MunkiCatalogBuilder
MunkiCatalogBuilder: ### The MunkiCatalogBuilder processor has been deprecated. It currently does nothing. It will be removed in the future. ###
Receipt written to /Users/gneagle/Library/AutoPkg/Cache/com.github.autopkg.gneagle.test/receipts/Test-receipt-20231109-171348.plist

Nothing downloaded, packaged or imported.

The second change is to the MunkiImporter processor. Previously, it did not reset the value of the munki_repo_changed variable between recipe runs, so if you were running multiple recipes, and one changed the repo, munki_repo_changed was reported as True for all remaining recipes. This behavior was intended to tell a processor to run makecatalogs after running a list of recipes if any of them changed the repo. But this ended up being implemented a different way that did not rely on the munki_repo_changed variable. Therefore, the behavior of this has been changed to reflect the documentation, that is, it reports if the current recipe caused a change to the repo.

Consider a run that runs a Firefox and a Chrome recipe. A new Firefox version is imported, but the Chrome version is already current in the repo. The prior behavior reported munki_repo_changed after running the Firefox recipe, and also after running the Chrome recipe.

In the new behavior, munki_repo_changed is reported as True only after the Firefox recipe:

MunkiImporter: Copied pkginfo to: /Users/Shared/munki_repo/pkgsinfo/apps/Firefox-119.0.1.plist
MunkiImporter:            pkg to: /Users/Shared/munki_repo/pkgs/apps/Firefox_DisneyAnimation-119.0.1.pkg
{'Output': <snip>
            'munki_repo_changed': True,
            'pkg_repo_path': '/Users/Shared/munki_repo/pkgs/apps/Firefox_DisneyAnimation-119.0.1.pkg',
            'pkginfo_repo_path': '/Users/Shared/munki_repo/pkgsinfo/apps/Firefox-119.0.1.plist'}}

followed by

MunkiImporter: Item GoogleChrome.dmg already exists in the munki repo as pkgs/apps/GoogleChrome-119.0.6045.123.dmg.
{'Output': {'pkg_repo_path': '/Users/Shared/munki_repo/pkgs/apps/GoogleChrome-119.0.6045.123.dmg'}}

Note that in the results for the Chrome recipe, munki_repo_changed is not reported as False; instead it is not reported at all. This is because of this existing code:
https://github.com/autopkg/autopkg/blob/dev/Code/autopkglib/__init__.py#L894-L905
Which causes an output variable to be printed only if it's Python "truthy" -- that is, empty dicts, arrays, and strings will not be printed, booleans with a value of False will not be printed, and numbers with a value of 0 will not be printed. Whether or not that is behavior to address is outside the scope of this PR.