They're unused now.

This is to avoid the final conversion from `NodeId` to `HirId`
during call to `Resolver::(clone|into)_outputs`.

encoded build artifacts.

Fix #70924.

Such splits arise from metadata refs into libstd.

This way, we can (in a follow on commit) continue to emit the virtual name into
things like the like the StableSourceFileId that ends up in incremetnal build
artifacts, while still using the devirtualized file path when we want to access
the file.

Note that this commit is intended to be a refactoring; the actual fix to the bug
in question is in a follow-on commit.

NativeLibrary(Kind) -> NativeLib(Kind)
NativeStatic -> StaticBundle
NativeStaticNobundle -> StaticNoBundle
NativeFramework -> Framework
NativeRawDylib -> RawDylib
NativeUnknown -> Unspecified

Rename fn_has_self_argument to fn_has_self_parameter

Rename AssocItemKind::Method to AssocItemKind::Fn

Refine has_no_input_arg

Refine has_no_input_arg

Revert has_no_input_arg

Refine suggestion_descr

Move as_def_kind into AssocKind
Signed-off-by: NRustin-Liu <rustin.liu@gmail.com>

Fix tidy check issue
Signed-off-by: NRustin-Liu <rustin.liu@gmail.com>

Makes code more compact and reduces nestig.

Previously, we threw away the `Span` associated with a definition's
identifier when we encoded crate metadata, causing us to lose location
and hygiene information.

We now store the identifier's `Span` in the crate metadata.
When we decode items from the metadata, we combine
the name and span back into an `Ident`.

This improves the output of several tests, which previously had messages
suppressed due to dummy spans.

This is a prerequisite for #68686, since throwing away a `Span` means
that we lose hygiene information.

Previously, metadata encoding used DUMMY_SP to represent any spans that
referenced an 'imported' SourceFile - e.g. a SourceFile from an upstream
dependency. These leads to sub-optimal error messages in certain cases
(see the included test).

This PR changes how we encode and decode spans in crate metadata. We
encode spans in one of two ways:

* 'Local' spans, which reference non-imported SourceFiles, are encoded
  exactly as before.
* 'Foreign' spans, which reference imported SourceFiles, are encoded
  with the CrateNum of their 'originating' crate. Additionally, their
'lo' and 'high' values are rebased on top of the 'originating' crate,
which allows them to be used with the SourceMap data encoded for that
crate.

The `ExternalSource` enum is renamed to `ExternalSourceKind`. There is
now a struct called `ExternalSource`, which holds an
`ExternalSourceKind` along with the original line number information for
the file. This is used during `Span` serialization to rebase spans onto
their 'owning' crate.