[KED-3023] Enable plugins to extend starter-aliases default list

Description

Is your feature request related to a problem? A clear and concise description of what the problem is: “I’m always frustrated when …”

We have at work a few kedro starters templates which enable to create kedro projects with a bunch of internal configuration (pre-commit, gitlab-ci, custom ConfigLoader…). We also have a custom plugin which modifies kedro’s internal (especially the CONF_ROOT constant and the CLI).

When we distribute our template insisde the organisation, we have to give the entire VCS path to the project to our user, and it is not very convenient. I wish we were able to decalre a new starter-alias in the plugin, and when the plugin is installed and auto-discovered by kedro, users can user:

kedro new --starter=my_starter where my_starter VSC path was declared in the plugin, maybe like this:

_PLUGIN_STARTER_ALIAS: ​{my_starter: path/to/VCS}

Context

Why is this change important to you? How would you use it? How can it benefit other users?

The 2 main benefits I expect are:

• it facilitates the distribution of templates, since it makes installation easier for end users
• it facilitates maintenance: if the template path changes for whatever reason (regrouping all the templates in a single repo, moving to another gitlab/github instances for orgnaisations internal reasons), the modification is transparent for end users

Possible Implementation

Add a _PLUGIN_STARTER_ALIAS constant in plugins which will be user to extend the https://github.com/quantumblacklabs/kedro/blob/bce62c824a4786e7cf9cc355b31840879ec851bf/kedro/framework/cli/starters.py#L31-L38 set.

It likely needs a bit more refactoring to make it a dict accepting different _STARTERS_REPO path which is currently a hardcoded path to a single one github repo.

[lorenabalan]

Linking here some alternative thinking on starter discoverability before we get tied up to a single solution/idea: https://github.com/quantumblacklabs/kedro-starters/pull/40#pullrequestreview-712884148

[Galileo-Galilei]

@lorenabalan I’ve read the discussion and I think that browsing github to find kedro-starters among community-developped examples may be a good idea, but comes with some caveats to keep in mind:

• it does not work for enterprise support (My company starter is not shared publicly and will likely never be)
• it ties the discovery to a single code-forge provider, i.e. github (gitlab or bitbucket, despite being less common, are serious contenders which should not be ignored IMHO)
• it may become overcrowded really fast (dozens of starters alreayd exists and the number keeps growing. It may be tedious to find in the CLI genererated list the one you want from a UX perspective).
• Discovery may be done either at runtime (=browse github when running the CLI command), but it assumes you have internet connection (which is not always the case on internal servers for security reasons) or at build time (=have a fixed list when you release a version, but it ties discovery to your realease process which sounds quite slow /bad)