Don't factor JLLs into the resolver decision when multiple update options are possible

[IanButterworth]

The package is usually the user-facing version not the JLL.

In some cases new JLL versions being available can force packages to be downgraded.

For instance FFMPEG_jll v6.1.1 exists but is incompatible with VideoIO after v1.0.9 (currently), when VideoIO took FFMPEG_jll on as a direct dep (to control compat), so this happens

(Foo) pkg> up
    Updating registry at `~/.julia/registries/General.toml`
   Installed BinaryProvider ─ v0.5.10
   Installed FFMPEG ───────── v0.2.4
   Installed FFMPEG_jll ───── v6.1.1+0
   Installed VideoIO ──────── v1.0.8
  Downloaded artifact: FFMPEG
  No Changes to `~/Documents/GitHub/Foo/Project.toml`
    Updating `~/Documents/GitHub/Foo/Manifest.toml`
  [b99e7846] + BinaryProvider v0.5.10
⌃ [c87230d0] ↓ FFMPEG v0.4.1 ⇒ v0.2.4
⌃ [d6d074c3] ↓ VideoIO v1.1.0 ⇒ v1.0.8
  [b22a6f82] ↑ FFMPEG_jll v4.4.4+1 ⇒ v6.1.1+0

This can't cleanly be fixed in the registry too, because before v1.0.9 VideoIO didn't have FFMPEG_jll as a direct dep, so we would have to add deps to old versions, which feels nonideal.

One strategy would be to ignore JLLs when counting the cost of different resolver update paths.
The other would be some reduced weighting for JLLs.

I prefer just ignoring JLLs.

[ChrisRackauckas]

I just hit this and agree, the user wants a working Julia package, not the latest JLL.