["Request"] Bind unary values for Nel

### What version are you currently using?

1.2.0-RC

### What would you like to see?

Sometimes, inside `Raise>`, a failed precondition stops the computation from going further, and short-circuiting is necessary.

Let's image a recursive tree. A node is valid if it satisfies the predicate `a()`, and all its children satisfy it as well. I'm writing this example with context receivers for readability, but it is already the case now.

```kotlin
sealed class Tree {
class A : Tree() {

context(Raise>)
override fun validate() = either {
ensure(a()) { nonEmptyListOf(Failure.A()) } // ← here

children.mapOrAccumulate {
it.validate().bind()
}.mapLeft { it.flatten() }
.bind()
}

}

class B : Tree() { … }
}
```

When there are multiple short-circuiting operations, writing `ensure() { nonEmptyListOf() }` is inconvenient and makes the code more complicated. Instead, the library could provide a variant of `ensure` and `ensureNotNull` that encapsulates this behavior:

```kotlin
@RaiseDSL
public inline fun Raise>.ensure(condition: Boolean, raise: () -> Error) {
contract {
callsInPlace(raise, AT_MOST_ONCE)
returns() implies condition
}
return if (condition) Unit else raise(nonEmptyListOf(raise()))
}

@RaiseDSL
public inline fun Raise>.ensureNotNull(value: B?, raise: () -> Error): B {
contract {
callsInPlace(raise, AT_MOST_ONCE)
returns() implies (value != null)
}
return value ?: raise(nonEmptyListOf(raise()))
}
```

As a bonus, what about a `RaiseNel` type alias?

Start by locating the existing `ensure` and `ensureNotNull` entry points and any tests covering `Raise` and `Nel`. Compare their current behavior with the proposed unary-value binding, then determine whether the `RaiseNel` type alias belongs in the same public API; done means the requested variants and alias are consistent with the library's existing contracts and tests.

Written by the indexing model from the issue text.