Singleton List refactor

[gautamsi]

closes #2838
ref #1639

built on top of #3012 #3011, see actual diff for this PR - https://github.com/keystonejs/keystone/pull/3013/files/d16188bfe8eeaec03b0fd23b6c1e9f741034494c..85ba50307242c50eaa84840e6ea2f1d8aded6e05?diff=unified&w=1

This is refactor from #2838. additional argument to list plugins is moved to #3011 and disabling ui based on access control in Item Detail page footer is also moved to #3012

this PR adds TWO way of handling singleton features:

. if you set { adminConfig: { singleton: true }, access: { delete: false } } (due to change in UI in this PR) this can give you plugin free UI version of singleton list. List view will redirect to first item in the list and you have no way to create a new item or delete the existing item.
1.1 if you also set create access to false and seed the list (create item on keystone.connect) then you do not need any plugin. you are already covered.

2. above setting (except 1.1) is set automatically by singleton plugin. It also adds ability to create first item then you can not create more item, attempting this would give error in GraphQL. seeding is optional.

UI portion of changes are split and will be in future PR.

how to use:

const { singleton } = require('@keystonejs/list-plugins');

keystone.createList('SettingsList', {
  fields: {
    name: { type: Text },
    slug: { type: Slug, from: 'name' },
    field2: { type: Text },
    field3: { type: Text },
    field4: { type: Text },
    field5: { type: Text },
  },
  plugins: [singleton()],
});

@timleslie: should we set create = false and enforce seeding to make use of this plugin (if you do not see, it is unusable). Or we leave it as recommended approach for single item list.

[changeset-bot]

🦋 Changeset is good to go

Latest commit: 9d688e2

We got this.

This PR includes changesets to release 2 packages

Name	Type
@keystonejs/list-plugins	Major
@keystonejs/cypress-project-login	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[gautamsi]

This plugin does not need argument. We have this pattern to call the plugin when adding to list, if there is no argument this nesting of function call can be avoided. should this be a pattern or dependent on plugin whether to add as [plugin] or as [plugin()].

[gautamsi]

@timleslie removed UI changes as requested

[MadeByMike]

Ok, so I had a really long play with this and I have to admit that although I am glad that this PR is cut-down and much more readable it's current implementation is a little bit lacking (an that is ok).

This is a good first step that highlights some limitations. The main things are:

1. GQL should be different. It makes no sense to get allSingleton then pluck the first item or to provide an where: { id: ??? } when there is only one
2. Remove uneeded GQL names
3. Should accept any key as a "list" name regardless of plural
4. We need to do some work on how this is presented in the AdminUI
5. Initial "item" should be created automatically?
6. Remove from dashboard

I have a demo project I want to share shortly that I'd like to iterate on with people to inform the next steps here.