[Chore] Minor conflict manager refactoring (duckdb/duckdb#18015)

[Chore] Minor conflict manager refactoring (duckdb/duckdb#18015)

Co-authored-by: krlmlr <krlmlr@users.noreply.github.com>

#18194)

### Overview

#15092 made it possible for ART
`PRIMARY/UNIQUE` indexes to have at most two row IDs per (unique) leaf.

Currently, the conflict manager (and `ART::VerifyLeaf`) still work with
the assumption that there can never be more than one row ID per conflict
hit. Since this assumption no longer holds, in some cases, we now have
to register conflict hits for up to two row IDs. Related issue:
duckdblabs/duckdb-internal#4924. Later in the
execution, we need to understand which of the two possible row IDs is
visible to the transaction (and the conflict manager).

As far as I can tell, this mostly kept working because we use a `vector`
for row ID scanning, which is order-preserving, and newer row IDs (more
likely the ones visible to the current transaction) overwrote older row
IDs.

### Changes in this PR

- Exposed `CanFetch` to `DataTable`, `LocalStorage`,
`RowGroupCollection` to determine whether a row ID is visible to a
transaction/in the local storage, or not.
- The conflict manager now has the capacity to register a secondary hit
for a conflict.

Also, I've refactored basically the entire conflict manager. That
refactoring includes removing the `ManagedSelection`, and a lot of code
paths. I think the number of lines only went up because I've added the
`CanFetch` stuff and because I've also added a lot of comments and some
formatting). 😅

This PR is a minor follow-up to
#18015 and next up is turning the
row ids into an unordered set instead of a vector.