There are situations when team developing T Token Dashboard needs to
locally test some functionalities using modified contracts, for example
ones with shorter authorization decrease delay. We decided to create a
`dapp-development` branch in each of the upstream modules of
`threshold-network/token-dashboard` CI module, which would store the
code of these modified contracts. In this PR we create a
`contracts-dapp-development-deployment-testnet` job which deploys the
contracts, creates an NPM package (with `dappdev<environment>` suffix
and `dapp-development-<environment>` tag) and publishes it to the NPM
registry. At the end of the job we don't have a step informing CI about
completion of the workflow because we don't want to start the deployment
of the T Token Dashboard (which will soon be added as a downstream
module to the CI config) on a public testnet using modified contracts.
The job gets triggered only as a result of `workflow_dispath` event from
a `dapp-development` branch. Currently only `goerli` environment is
supported. We don't run system and unit tests for `dapp-development`
branch, as the tests are not configured to work with the modified
contracts.
Generally, the goal of the changes is to have the full set of
dapp-development-friendly contracts deployed to the NPM registry, so
that the dApp developers could quickly use them by upgrading the
`token-dashboard` dependencies using `yarn upgrade
<package-name>@dapp-development-goerli`.
If the workflow gets dispatched from a different branch than
`dapp-development`, the deploy will behave as it used to, publishing
package with deployed unmodified contracts to the NPM registry under
`<environment>` tag.

The contracts deployed in the
`contracts-dapp-development-deployment-testnet` job will be used by dApp
developers to build their local environments and deploy dApp previews.
We want more flexibility there than on the public-facing testnet dApp and
we want to use different deployer accounts for those two different types
of testnet dApps.

Newer versions of actions used in our workflows are available.

Changes not intended for merge to `main`.

We don't want to fill the default value with value that is supported, to
prevent from accidental dispatches of the workflow by people who don't
fully understand how the inputs should be configured. Previously we used
explicitely incorrect default value, but that may be too much and may be
a bit confusing. Let's leave the input without default.

Previously `-` was not supported as a value of `environment` property in
the `npm-version-bump` action. Now action supports hyphens and we can
change the suffix to more readible format.

We no longer use `/solidity` in the name of the `keep-core` CI modules. We
already replaced the old names with the new ones, but we missed one place where
the old names were still being used. This commit fixes that.