Remove MintReward and introduce PayRewardFromAccount

[svyatonik]

Right now there's a single implementation of PaymentProcedure for the pallet-bridge-relayers - it is the MintReward, which just mints relayer reward. Minting is not actual anymore. Instead the reward will be paid from some account (sovereign account of the parachain at bridge hub), so having PayRewardFromAccount would be great

[acatangiu]

If PayRewardFromAccount is a runtime configurable, then the bridge uses a single (sovereign) account to pay all rewards regardless of the message (Source, Destination).

This is fine for now, but in the future we might want to implement a more complex (Source, Destination) -> PayRewardFromAccount mapping to allow better control of which messages bridging costs are paid out by whom.

[svyatonik]

If PayRewardFromAccount is a runtime configurable, then the bridge uses a single (sovereign) account to pay all rewards regardless of the message (Source, Destination).

This is fine for now, but in the future we might want to implement a more complex (Source, Destination) -> PayRewardFromAccount mapping to allow better control of which messages bridging costs are paid out by whom.

One of solutions would be to isolate different "bridges" (i.e. pairs of (Source, Destination)) in dedicated message lanes. E.g. Statemine <> Statemint would be lane 0x00000000, some other bridge 0x00000001 and so on. Then we can support instances in pallet_bridge_relayers and use different instances to serve different lanes. But it would mean that set of such bridges is somewhat static - we'll need to do a runtime upgrade(s) to "open" a lane.