Nested SaveOperation has_one doesn't account for needs

Nobody has claimed this yet.

If you have a nested SaveOperation, and use the `has_one` declaration, it won't account for `needs` on that nested SaveOperation.

Right now, we just pass in `params` to the top operation, and that gets passed down. To do this, we may either need a refactor of how the nested stuff works, or add in some new syntax. One suggestion I'd be cool with seeing is maybe the `has_one` creates a `needs` on the parent that passes in a NamedTuple

```crystal
class SaveParent < Parent::SaveOperation
has_one child : SaveChild
end

SaveParent.create(params, child: {...}) do |o, p|
end
```

Then in this example, if the `SaveChild` has `needs` or whatever, that can be explicitly specified. If the `SaveChild` doesn't have `needs`, then maybe it's just empty? Type safety gets a little foggy with that.

Start by tracing nested SaveOperation handling for a has_one declaration and how params are passed from the parent operation to the nested operation. Compare that flow with how needs are declared and supplied. Done means a nested SaveChild can receive its needs through SaveParent while preserving clear type-safe behavior for children with or without needs.

Written by the indexing model from the issue text.