Support variable window frame boundaries in the `Expr::WindowFunction` data model.

### Is your feature request related to a problem or challenge?

The current window function implementation only supports constant window frame boundaries. This restriction is reflected in the data model as well by the fact that `WindowFrameBound` is defined as

```
pub enum WindowFrameBound {
Preceding(ScalarValue),
CurrentRow,
Following(ScalarValue),
}
```

rather than

```
pub enum WindowFrameBound {
Preceding(Expr),
CurrentRow,
Following(Expr),
}
```

In my particular use case I have a need for variable frame boundaries to be able to compute aggregates over hierarchies modeled as nested sets. I'm thinking of working on a patch that makes the above modification to `WindowFrameBound` and pushes the check that the `Expr` is actually a `Expr::Literal` down to the planning stage. Is that a change that would be acceptable?

### Describe the solution you'd like

Adjust `WindowFrameBound` from

```
pub enum WindowFrameBound {
Preceding(ScalarValue),
CurrentRow,
Following(ScalarValue),
}
```

to

```
pub enum WindowFrameBound {
Preceding(Expr),
CurrentRow,
Following(Expr),
}
```

and check for `Expr::Literal` during planning.

### Describe alternatives you've considered

None; open to other suggestions.

### Additional context

I read the documentation and experimented with a couple of SQL implementations. Most don't seem to support variable window frame boundaries, but Oracle does. So fwiw, there's at least one precedent for supporting this.

Start with the Expr::WindowFunction data model and the WindowFrameBound definition shown in the issue, then trace where window-frame bounds are validated during planning. The work is done when variable Expr bounds are represented and literal validation occurs at planning time, with the affected window-function behavior covered by the project’s existing tests.

Written by the indexing model from the issue text.