[API Proposal]: Segments collection and slicing

### Background and motivation

The individual parts of a path are not reachable. Callers who need to count the depth of a path, inspect the second segment, or rebuild a path from a subset of its parts have to split the string themselves and then reason about separators and rooting. The library already accepts the range operator through `path / ..`, so exposing the segments and allowing slicing would complete that story.

### API Proposal

```C#
namespace Pathy
{
public readonly struct ChainablePath
{
public IReadOnlyList Segments { get; }

public string this[int index] { get; }
public ChainablePath this[Range range] { get; }
}
}
```

### API Usage

```C#
var path = ChainablePath.From("c:/work/repo/src/Pathy/ChainablePath.cs");

path.Segments.Count; // number of parts
path[^1]; // "ChainablePath.cs"
path[..^2]; // c:/work/repo/src
path[2..]; // repo/src/Pathy/ChainablePath.cs
```

This reads well next to the existing range support:

```C#
var sibling = path / .. / "ChainablePathExtensions.cs";
```

### Alternative Designs

* Only expose `Segments` and let callers rebuild a path by chaining. That works but is noisy, and it is exactly the kind of boilerplate the library exists to remove.
* Add explicit `Skip(int)` and `Take(int)` methods instead of an indexer. Less idiomatic for modern C#, but available on every target framework.

### Risks

The indexer taking a `Range` is only available on the frameworks that support `System.Range`, so it has to be conditionally compiled the same way the existing range operator is. It needs to be clear whether the root (`c:` or the leading separator) counts as a segment, and slicing away the root has to produce a sensible relative path rather than a corrupt absolute one.

Start with ChainablePath and the existing range-operator implementation, including its conditional framework support. Resolve how roots count as segments and how slicing affects rooted paths, then define the expected Segments and indexer behavior; the work is done when those semantics are implemented consistently and verified across supported targets.

Written by the indexing model from the issue text.