Add async feature to operations / bulk query updates

No clue how this would work just yet, but it would be neat if we had a way to tell operations and bulk query updates that they can run in the background because we don't need their return values.

For example, in Lucky, you might have a login action that tracks some data on login. The data tracking would currently be blocking and the user can't be logged in until that operation completes. In this case, you'd probably want to create a background job, and move all of the operation logic there. The downside is this now means you need background job processing, and it adds a lot of additional code just for something you want to run in the background real quick. The next solution might just be to use `spawn`, but now you're throwing spawns all over the place.

Carbon has the idea of a "deliver later" strategy https://github.com/luckyframework/carbon/blob/main/src/carbon/deliver_later_strategy.cr which defaults to using `spawn`, but allows you to setup mosquito, or sidekiq, or whatever you want to process the emails later. I think it would be cool if Avram did this for operations and such.

```crystal
StoreLoginInfo.create_async!(user: user)

SessionQuery.new.user_id(user.id).update_async(state: Session::State::LoggedOut, when: Time.utc)
```

```crystal
# Generic examples
class Avram::SpawnStrategy < Avram::RunLaterStrategy
def run_async(&block)
spawn do
block.call
end
end
end

class Avram::MosquitoStrategy < Avram::RunLaterStrategy
def run_async(&block)
SomeJob.new.enqueue
end
end
```

Start by reviewing Avram's operations and bulk query update APIs, then compare Carbon's deliver_later_strategy.cr linked in the issue. The issue does not name implementation files or tests; done would require a settled async strategy and API design for both examples, with coverage for the chosen execution strategies.

Written by the indexing model from the issue text.