Görli became a recommended test network after Ropsten's deprecation
notice (https://blog.ethereum.org/2022/06/21/testnet-deprecation/).
We're modifying GitHub Actions workflow for deploying contracts to
support the deployment on Görli. We're also leaving the possibility of
deployment on Ropsten (this will be removed once we have the Görli
deployment battle-tested and Ropsten gets shut down).
We also change the way we handle `keep-core` dependency - in V2 of our
system we'll no longer planning to publish ne `keep-core` packages -
hence we hardcode used version of the package for given testnet.

NOTE: We're temporarily using some testing configuration in the
workflow, which needs to be removed before merge to `main`.

As the Ropsten testnet becomes deprecated in the near future, we are
switching to deployment on Goerli. If deployment on Ropsten will be
needed in the interm period, we will do it manually, not via GH Actions.

Change is only temporary, it should be reverted before merge to `main`.

We are removing the temporary configuration used for workflow testing.
We are also bumping the version of used custom GH actions from `v1` to
`v2`, as `v2` uses the new order of modules executions.

We tag the latest `@keep-network/keep-core` package containing contracts
migrated on some environment with tag that is a name of that
environment. We can use that tag instead of the explicit version when
resolving contracts of dependant projects.

Right now we only support `goerli` network and we expect that the
workflow (when triggered manually) is always dispatched with this
`environment`. Previously we introduced
`github.event.inputs.environment == 'goerli'` condition to not run the
deploy job if workflow gets accidentally run on a different environment.
But even without this condition we don't risk publishing of a package
with some invalid contracts - deploy will fail either due to
unsupported `environment` or due to incorrect account being used.
Actually, returning error instead of cleanly exiting the workflow may be
a better idea in case wrong `environment` is provided - this will alarm
the scheduler that something went wrong with the deployment.