This change allows edges that don't fully cover their method matches to
be properly tracked through serialization. When fully_covers is false
(indicating incomplete method coverage), we encode the method count as
negative in the edges array to signal that compactly.

This commit introduces a new dispatch status bit to track when a method
has other methods that are not more specific than it, enabling better
optimization decisions during method dispatch.

Key changes:
  1. Add METHOD_SIG_LATEST_HAS_NOTMORESPECIFIC bit to track methods with
     non-morespecific intersections
  2. Add corresponding METHOD_SIG_PRECOMPILE_HAS_NOTMORESPECIFIC bit for
     precompiled methods
  3. Refactor method insertion logic:
     - Remove morespec_unknown enum state, compute all morespec values upfront
     - Convert enum morespec_options to simple boolean logic (1/0)
     - Change 'only' from boolean to 'dispatch_bits' bitmask
     - Move dispatch status updates before early continues in the loop

…58916)

These objects satisfy the requirements of the `MarkdownElement`
interface (such as implementing `Markdown.plain`), so they should be
subtypes of `MarkdownElement`. This is convenient when defining
functions for `MarkdownElement` in other packages.

This lets you easily inspect IR associated with "Functor-like" methods:
```julia
julia> (f::Foo)(offset::Float64) = f.x + f.y + offset
julia> code_typed((Foo, Float64))
1-element Vector{Any}:
 CodeInfo(
1 ─ %1 = Base.getfield(f, :x)::Int64
│   %2 = Base.getfield(f, :y)::Int64
│   %3 = Base.add_int(%1, %2)::Int64
│   %4 = Base.sitofp(Float64, %3)::Float64
│   %5 = Base.add_float(%4, offset)::Float64
└──      return %5
) => Float64
```

This is just a small convenience over `code_typed_by_type`, but I'm in
support of it (even though it technically changes the meaning of, e.g.,
`code_typed((1, 2))` which without this PR inspects
`(::Tuple{Int,Int})(::Vararg{Any})`

We should probably update all of our reflection machinery (`code_llvm`,
`code_lowered`, `methodinstance`, etc.) to support this "non-arg0" style
as well, but I wanted to open this first to make sure folks like it.

When invoking any "functor-like", such as a closure:
```julia
bar(x) = @noinline ((y)->x+y)(x)
```
our IR printing was not showing the arg0 invoked, even when it is
required to determine which MethodInstance this is invoking.

Before:
```julia
julia> @code_typed optimize=true bar(1)
CodeInfo(
1 ─ %1 = %new(var"#bar##2#bar##3"{Int64}, x)::var"#bar##2#bar##3"{Int64}
│   %2 =    invoke %1(x::Int64)::Int64
└──      return %2
) => Int64
```

After:
```julia
julia> @code_typed optimize=true bar(1)
CodeInfo(
1 ─ %1 = %new(var"#bar##2#bar##3"{Int64}, x)::var"#bar##2#bar##3"{Int64}
│   %2 =    invoke (%1::var"#bar##2#bar##3"{Int64})(x::Int64)::Int64
└──      return %2
) => Int64
```

As a follow-up to #57911, this
updates:
 - `Base.method_instance`
 - `Base.method_instances`
 - `Base.code_ircode`
 - `Base.code_lowered`
 - `InteractiveUtils.code_llvm`
 - `InteractiveUtils.code_native`
 - `InteractiveUtils.code_warntype`
 
 to support "functor" invocations.
 
e.g. `code_llvm((Foo, Int, Int))` which corresponds to `(::Foo)(::Int,
::Int)`

This is a bugfix and code cleanup, since it wasn't properly encoding and
checking for newly "missing"-type backedges `fully_covering` during
verification.

Co-authored-by: Claude <[email protected]>

…58904)

I've run into this question several times, that might count as
"frequently asked".