[API Proposal]: EnsureDirectoryExists returning the path so it chains

### Background and motivation

`CreateDirectoryRecursively` returns `void`, which breaks the fluent style everywhere it is used. The very common "make sure this output directory exists, then write a file into it" pattern needs two statements and a temporary variable, even though it reads as one thought.

### API Proposal

```C#
namespace Pathy
{
public static class ChainablePathExtensions
{
public static ChainablePath EnsureDirectoryExists(this ChainablePath path);
}
}
```

The method is idempotent and returns the same path, so it can sit in the middle of a chain.

### API Usage

```C#
// Today
var output = ChainablePath.Current / "artifacts" / "logs";
output.CreateDirectoryRecursively();
var logFile = output / "build.log";

// With this proposal
var logFile = (ChainablePath.Current / "artifacts" / "logs").EnsureDirectoryExists() / "build.log";
```

### Alternative Designs

* Change `CreateDirectoryRecursively` to return `ChainablePath`. This is source compatible for callers but a binary breaking change; for a source-only package that may be acceptable, and it avoids having two methods that do the same thing. Worth deciding explicitly.
* Name it `EnsureExists`. Less clear about what gets created when the path looks like a file.

### Risks

Two near-identical methods invite confusion about which to use, so the documentation needs to be clear, or the older method should be retired. Behaviour when the path already exists as a *file* must be defined rather than left to the underlying exception.

Start by locating ChainablePath and the existing CreateDirectoryRecursively implementation and its callers. Decide whether to add EnsureDirectoryExists or change the existing return type, define behavior when the path is an existing file, and document or test the chosen chaining behavior.

Written by the indexing model from the issue text.