Finish removing staking delay exits migration

[4meta5]

Add this after the migration in #662 is executed by all networks

[JoshOrndorff]

In the future, the migration code itself should kill this storage item if the runtime upgrade has already executed. This is possible but wasn't implemented in the original migration (my bad!)

Is that possible? Isn't the migration code what set this value in the first place? One option to do this in fewer PRs would be to combine this PR with the one in #662 without using the strongly typed wrapper, and instead kill the storage item using https://crates.parity.io/frame_support/storage/migration/fn.take_storage_value.html

This will do the take operation with keys that you supply manually. Therefore the storage item type is no longer necessary.

[4meta5]

Your suggestion is the only way.

I thought I could kill the storage value in the else branch of if the migration already ran, but killing the storage item would set it to bool::default() which is false and then the migration could run accidentally again (defeating the purpose of the storage item in the first place).

[4meta5]

We'll know this can be merged when moonriver parachain_staking::DelatNominationExitsMigration == false because the previous migration (#662 ) kills that storage item and this migration removes it.

As of now, this is not the case (so the prerequisite migration has not yet been executed on moonriver)