The idea here is that if we detect that a package is built-in, we
"pre-compute" part of the transaction and resolve the rest.  This does
not install any unnecessary dependencies.

When `package-install' is invoked interactively without a prefix
argument, the "new" code cannot run, since none of the completion
candidates satisfy `package--upgradable-built-in-p' (or whatever we end
up calling the predicate).  Note that (package-install 'eglot) does
download code, but I believe that this is the correct approach and would
align with what João wanted.

>> +(defun package--upgradable-built-in-p (package)
>> +  "Check if a built-in PACKAGE can be upgraded.
>> +This command differs from `package-built-in-p' in that it only
>    ^^^^^^^^^^^^
> This is not a command, this is a function.

I will address these issues as soon as we have working code.

> Also, the name has a problem I pointed out earlier in this discussion:
> "upgradeable" does not tell well enough what the function tests.
>
>> @@ -2187,7 +2210,9 @@ package-install
>>    "Install the package PKG.
>>  PKG can be a `package-desc' or a symbol naming one of the
>>  available packages in an archive in `package-archives'.  When
>> -called interactively, prompt for the package name.
>> +called interactively, prompt for the package name.  When invoked
>> +with a prefix argument, the prompt will include built-in packages
>> +that can be upgraded via an archive.
>
> I wonder whether an invocation with the prefix argument should include
> _only_ built-in packages in the prompt?  This could be a useful
> feature regardless, and so would allow us to keep this option for
> future uses.
>
> Finally, there's still discussion going on whether built-in packages
> should be handled only by package-update, not by package-install,
> since built-in packages are always "installed".  WDYT?