Rename erc20next to erc20

[golmek]

Payment Driver - Backward compatibility

• New Payment driver will get name of old payment driver erc20.
• Decorate demand API will return new property - protocol.version , which will limit Requestors to accept only new Providers (version ≥ 2)
• Provider offer need new property and constraint protocol.version , which will limit Provider to accept only new Requestors (version ≥ 2)

	Provider v1	Provider v2
Requestor - v1	OK (only v1 will not reject, because they do not have properties)	NOT OK (constraint on provider)
Requestor - v2	NOT OK (constraint on requestor)	OK

"payment":{
   "protocol.version": 2,
   "debit-notes":{
      "accept-timeout?":240
   },
   "platform":{
      "erc20-rinkeby-tglm":{
         "address":"0x86a269498fb5270f20bdc6fdcf6039122b0d3b23"
      },
      "zksync-rinkeby-tglm":{
         "address":"0x86a269498fb5270f20bdc6fdcf6039122b0d3b23"
      }
   }
}

Benefits:

1. Lack of changes in older applications as we do not change erc20 name
2. No communication to end user is needed
3. Not accepted payments on old driver will be automatically migrated to the new one.
4. Change is transparent for SDK

Drawbacks:

1. We split network - new payment driver need to propagate through network and achieve > 50%. We need to phase out AR migration to new payment driver over time.
2. Accepted but not settled payments on old driver will not be automatically migrated to the new one - payments will stuck forever. It should impact very small amount of users.

Source: https://hackmd.io/ghBbvjtkTnujJPbgm977YA?view

Acceptance Criteria:

• Rename erc20next to erc20
• Add ProtocolVersion to platform in the offer
• Constraint ProtocolVersion in the demand to prevent interacting with old providers

[golmek]

After discussion with Requc:
constraint on provider - was removed.
consequently - new Provider will be able to talk with new and old Requestors