Fix runtime upgrade test by using governance instead of SUDO

[ghzlatarev]

Description

closes: #323

• Change trigger condition of the CI test, before it wasn't getting triggered on tags. Also the if condition for one of the sub-jobs was only being triggered for dolphin label.

• Use governance instead of sudo account to submit runtime upgrade extrinsics. The old method could only upgrade a special ci chain-spec which included sudo in its genesis. That special chain-spec is now removed alltogether and we can trigger with calamari-dev chain-spec.

• Migrate the test JS/TS code from Dev-Tools repo to tests folder in this repo

• Use mocha framework to assert the test conditions (that spec_version has increased)

• Update the CI test to use the new mocha test.

• Successful run: https://github.com/Manta-Network/Manta/actions/runs/3720978998

---

Before we can approve this PR for merge, please make sure that all the following items have been checked off:

• Linked to Github issue with discussion and accepted design OR have an explanation in the PR that describes this work.
• Added one label out of the L- group to this PR
• Added one or more labels from the A- and C- groups to this PR
• Explicitly labelled A-calamari, A-dolphin and/or A-manta if your changes are meant for/impact either of these (CI depends on it)
• This PR is targeted against the current Milestone ( otherwise discuss if it can be added in time)
• Re-reviewed Files changed in the Github PR explorer.

Situational Notes:

• If adding functionality, write unit tests!
• If importing a new pallet, choose a proper module index for it, and allow it in BaseFilter. Ensure every extrinsic works from front-end. If there's corresponding tool, ensure both work for each other.
• If needed, update our Javascript/Typescript APIs. These APIs are officially used by exchanges or community developers.
• If modifying existing runtime storage items, make sure to implement storage migrations for the runtime and test them with try-runtime. This includes migrations inherited from upstream changes, and you can search the diffs for modifications of #[pallet::storage] items to check for any.
• If runtime changes, need to update the version numbers properly:
  • authoring_version: The version of the authorship interface. An authoring node will not attempt to author blocks unless this is equal to its native runtime.
  • spec_version: The version of the runtime specification. A full node will not attempt to use its native runtime in substitute for the on-chain Wasm runtime unless all of spec_name, spec_version, and authoring_version are the same between Wasm and native.
  • impl_version: The version of the implementation of the specification. Nodes are free to ignore this; it serves only as an indication that the code is different; as long as the other two versions are the same then while the actual code may be different, it is nonetheless required to do the same thing. Non-consensus-breaking optimizations are about the only changes that could be made which would result in only the impl_version changing.
  • transaction_version: The version of the extrinsics interface. This number must be updated in the following circumstances: extrinsic parameters (number, order, or types) have been changed; extrinsics or pallets have been removed; or the pallet order in the construct_runtime! macro or extrinsic order in a pallet has been changed. You can run the metadata_diff.yml workflow for help. If this number is updated, then the spec_version must also be updated
• Verify benchmarks & weights have been updated for any modified runtime logics

[Garandor]

LGTM, great PR!