Fix Sign Engines's session request logic

[quetool]

Description

There was a bad decision-making process inside Sign Engine in regards of session requests where a wallet could use methods handlers AND onSessionRequest events but not separately.

The data carried by both logics didn't change, method handler will still make use of topic and parameters and onSessionRequest event will still make use of SessionRequestEvent object which contains id, topic, method, chainId and params but by fixing the decision-making logic inside Sign Engine we now resolve this issue #258

APPROVE SESSIONS:

BEFORE PR:

• Until now, most developers were relying on generatedNamespaces object inside of SessionProposalEvent's params, which is a handy object that determines automatically which methods are supported based on which handlers are registered with registerRequestHandler()

AFTER PR:

• Now, generatedNamespaces is still a valid object to be used to approve a session but if the wallet developer wants to handle session requests using onSessionRequest events (without registering a handler) then they will need to pass to approveSession() a custom set of namespaces that would include those methods without a registered handler. (This is similar to any other SDK)

HANDLING SESSION REQUESTS:

BEFORE PR:

• Until now, only by registering request handlers was possible to handle a session (method) request and only after handling it with the registered handler, only then, an onSessionRequest event was emitted (which was useless since the request was already being responded at that point).
• Furthermore, and more importantly, there was no way of handling the request with onSessionRequest since the onSessionRequest's event was being emitted only if a request handler was registered before and if a request handler was not registered for a given method then that method was considered unsupported. This is wrong!

AFTER PR:

• Now, if a method handler is registered for a given method then that handler is going to be used to handle the request WITHOUT emitting an onSessionRequest event (which was anyway useless before, as mentioned above)
• Now, if no method handler is registered for a given method, an onSessionRequest event will be emitted for that request and the request would have to be handled in the onSessionRequest subscription method. If there are no methods handlers registered then every request will emit an onSessionRequest event to be handled.

How Has This Been Tested?

• Smoke and manual tests.
• Fixed UT accordingly.

Due Dilligence

• Breaking change
• Requires a documentation update