Blanket authorization

[bbenligiray]

Closes #47

The current implementation of RequesterAuthorizers allow endpoint with ID 0 to be whitelisted to support api3dao/airnode#1527 However, during our research, we realized that using the endpoint with ID 0 for this purpose is not appropriate and that should be a proper endpoint with an ID. Then, instead of removing the endpoint-specific authorization functionality, I used authorizations with endpoint ID 0 as a blanket authorization across all endpoints of the Airnode.

Although the current ERC20-based monetization contracts can be updated according to this, I didn't bother because they have gone obsolete #45

[acenolaza]

Code changes look good for current solution but since endpointId is basically the hash of oisTitle + endpointName, wouldn't it be semantically more correct to use the hash of just oisTitle instead of bytes32(0) to allow all endpoints for a specific OIS?

[bbenligiray]

That's also an option but then the Airnode would have to check authorization for two endpoints IDs (hash(OIS title+endpoint name) and hash(OIS title)), though this is not a very strong argument against it.
I mainly added this for the monetization story and there the authorization is designed to happen for all endpoints of an Airnode (rather than an OIS). That's because it is the API provider's brand value that is being monetized rather than a specific set of endpoints, so they buyer will expect to get access to all future endpoints too (and the API provider can always create a new mnemonic/address if they really want to work around this).

[Ashar2shahid]

I like the OIS approach that @acenolaza suggested, but I think using 0 for system wide access makes sense and also help to verify easily onchain if someone gets verified because they don't have to deal with endpointIds.