more structured types for log listing

[zachschuermann]

we have a handful of assumptions that float around which aren't well-encoded into the type system, e.g.

1. ascending_commit_files (just a name tells you sorting)
2. checkpoint_parts: Vec has all the same version
3. etc.

we should encode some of these guarantees (e.g. in list_log_files_with_version output types):

// instead of
pub(crate) fn list_log_files_with_version(
    fs_client: &dyn FileSystemClient,
    log_root: &Url,
    start_version: Option<Version>,
    end_version: Option<Version>,
) -> DeltaResult<(Vec<ParsedLogPath>, Vec<ParsedLogPath>)> {
// ...
}

// replace with
pub(crate) fn list_log_files_with_version(
    fs_client: &dyn FileSystemClient,
    log_root: &Url,
    start_version: Option<Version>,
    end_version: Option<Version>,
) -> DeltaResult<(SortedCommitFiles, CheckpointParts)> {
// ...
}

struct SortedCommitFiles {
    commit_files: Vec<ParsedLogPath>,
    is_ascending: bool,
    end_version: Version
}

struct CheckpointParts {
    checkpoint_parts: Vec<ParsedLogPath>,
    checkpoint_version: Version
}

[zachschuermann]

related: redundant checks/filtering on commits after checkpoint

in list_log_files_with_version we have:

// [snip]
checkpoint_parts = complete_checkpoint;
commit_files.clear(); // Log replay only uses commits after a complete checkpoint
// [snip]

and again in LogSegment::try_new() (which I moved around a little but was there in the control flow anyways):

// Commit file versions must be greater than the most recent checkpoint version if it exists
let checkpoint_version = checkpoint_parts.first().map(|checkpoint_file| {
    ascending_commit_files.retain(|log_path| checkpoint_file.version < log_path.version);
    checkpoint_file.version
});