autoload/preload strategy

For some use cases its desirable to preload a users data set.

You can do this currently by using the HyperModel.load method.

However its clunky. For example:

```ruby
HyperModel.load do
Task.for_user(Application.acting_user_id).each do |task|
%i[description due_date].each { |attr| task.attr } # force load each attribute
task.comments.each do |comment|
%[comment created_at].each { |attr| comment.attr }
comment.commenter.name
end
end
end
```

of course we can build a nicer DSL for this:

```ruby
Task.for_user(Application.acting_user_id).preload(
:description,
:due_date,
comments: [
:created_at,
:comment,
{ commenter: :name } # short for { commenter: [:name] }
]
)
```

However this is not the hyperstack way is it? There is a lot of redundancy here. For example lets say you add a `title` to the `Task` model. You now have to add the `title` field someplace in the UI, as well as adding it to this prefetch.

In a way it's not the worst thing in the world, since the system will still function correctly, it will just not preload the new `title` attribute, but it will load it eventually.

BUT WAIT... in order for the attributes to be accessible to the client there must be a policy in place giving permission to see that attribute. And by the way the same goes for scopes and relationships.

So perhaps this whole thing can be reduced a single macro added to ActiveRecord base, that would typically be used in the top level router component:

```ruby
class TaskerApp < HyperComponent
include Preloader
before_mount do
preload_using { for_user(Application.acting_user_id) }
end
...
end
```

`preload_using` expects the block to yield an active record relationship, which is then forwarded to the server for processing. It then takes every record in that relationship and returns all the attributes in that relationship that the current user has access to. Any relationships associated with the record are also checked, and if access to that relationship is permitted to the current user, then it is also traced recursively.

Probably need some additional bells and whistles for finer control.

The whole thing can be built as a nice little separate gem with just a little white box knowledge of some internal HyperModel APIs.