FR: Extract the default index into its own crate

[rishiad]

Is your feature request related to a problem? Please describe.
The default_index implementation is currently bundled into jj-lib, and its persistence layer is tightly coupled to the local filesystem.

Downstream projects implementing custom storage backends may still want to reuse jj’s existing default index algorithm and on-disk format without depending on the rest of jj-lib. Extracting it would also align with the jj-core crate structure proposed in #6284.

Describe the solution you'd like

Move the default index implementation into a new jj-default-index crate.

jj-core would own the generic index and index-store traits, while jj-default-index would own the default index implementation and persistence through a configurable storage abstraction.

The new crate could introduce a storage interface like this (pseudocode):

  pub trait DefaultIndexStorage {
      async fn read_op_link(op_id: &OperationId) -> Result<...>;
      async fn write_op_link(op_id: &OperationId, bytes: &[u8]) -> Result<...>;

      async fn read_commit_segment(id: &CommitIndexSegmentId) -> Result<...>;
      async fn write_commit_segment(id: &CommitIndexSegmentId, bytes: &[u8]) -> Result<...>;

      async fn read_changed_path_segment(id: &ChangedPathIndexSegmentId) -> Result<...>;
      async fn write_changed_path_segment(id: &ChangedPathIndexSegmentId, bytes: &[u8]) -> Result<...>;

      async fn reinit() -> Result<...>;
  }

The existing filesystem-backed persistence would remain the default implementation. Downstreams could provide alternative implementations backed by databases, object stores, or other storage systems.

This would allow downstream projects to reuse jj’s default index algorithm and format while replacing only its persistence layer.