Make haskey(::@Kwargs{item::Bool}, :item) constant-fold

[topolarity]

Resolves #59269.

Makes #59292 somewhat worse by doubling-down on the same assumptions.

We should straighten out that issue properly, but I don't see any reason not to get better inference in the mean time for the very common @Kwargs case. We are already relying on those assumptions in Base (as that issue demonstrates), and @JeffBezanson says that this functionality wasn't intended to be supported:

I think the use case for it is picking not a subset, but alternate key set, specifically linear or cartesian indices for arrays. [...] So go ahead and add that haskey method

edit: now also resolves #59292.

[JeffBezanson]

Yes I think this is ok. Note Base.Pairs was not exported (though is now public). I think we should add an admonishment to the docstring for Pairs that the keys must match the keys of the data.

We may have thought of extending Pairs to allow e.g. subsetting keys, but obviously we are not going to implement that now. I think it really is out of scope and better suited to a different view-like type.

[JeffBezanson]

Idea to consider: we could make this "safer" by making pairs(x::NamedTuple) return a Pairs{...,...,Nothing,typeof(x)} so we statically know the keys match the original namedtuple plus we save a pointer.

[topolarity]

Idea to consider: we could make this "safer" by making pairs(x::NamedTuple) return a Pairs{...,...,Nothing,typeof(x)} so we statically know the keys match the original namedtuple plus we save a pointer.

I tried this approach, and I think I like it better. .itr is a "private" field, so it should be safe for us to change it (keys(::Pairs) is unaffected)

That puts us in a better position to resolve #59292 (merge is easily fixed now, although values(::Pair) remains an issue)