Data on actions

[emmatown]

This adds an experimental __data option on actions which defines what fields from the list the action should passed. true can be passed to receive all fields in which the types will use the list's update input or an object can be provided to specify specific fields and then those fields will be sent when the action is called from the Admin UI.

For example, it could be used in our usecase-versioning example to have an action that receives the version field:

actions: {
  publish: action({
    access: allowAll,
    ui: {
      label: 'Publish',
      itemView: { actionMode: { enabled: true } },
    },
    graphql: {
      __data: {
        version: true,
      },
    },
    resolve: async ({ where, data }, context) => {
      return context.sudo().db.Post.updateOne({
        where,
        data: {
          isPublished: true,
          version: data.version,
        },
      })
    },
  }),
},

The GraphQL for the example looks like this:

  publishPost(where: PostWhereUniqueInput!, data: PublishPostData!): Post
  publishPosts(data: [PublishPostArgs!]!): [Post]
}

input PublishPostData {
  version: Int!
}

input PublishPostArgs {
  where: PostWhereUniqueInput!
  data: PublishPostData!
}

Note this PR involves a change to the many action types and array of {ActionSingular}Args is passed instead of a {ListSingular}WhereUniqueInput which happens even if data isn't specified.

type Mutation {
  votePost(where: PostWhereUniqueInput!): Post
  votePosts(data: [VotePostArgs!]!): [Post]
}

input VotePostArgs {
  where: PostWhereUniqueInput!
}

Also, to support the types for this, actions must now also be declared with an action function like shown in the example.

Also, separately, we weren't actually evaluating the client side filters for actionMode, this fixes that.

No changeset since actions haven't been properly released.

[emmatown]

Note because this wasn't requested previously, itemView.actionMode called with the actual item was never actually used