Use morph/client package in inner ring instead of invoke

[alexvanin]

Right now inner ring has two ways to invoke chain methods:

• by using wrapper functions in innerring/invoke package,
• by using wrapper structures from morph/client package.

(1) functions were designed to be light weight wrappers around client. (2) structures were designed with complex logic inside: taking and marshaling structures from arguments, using predefined invocation fee, etc.

(2) already used in storage node and has some adoption in inner ring for various processors. I suppose we can completely drop wrapper functions from innerring/invoke and use only morph/client wrapper instances to avoid this duality.

[alexvanin]

After #505 we need to:

• use morph/client wrappers in inner ring processors,
• simplify static client methods.

Wrappers

As for wrappers right now there are many places where low level morphClient used to fetch and parse data.

// pkg/innerring/innerring.go
func (s *Server) initConfigFromBlockchain() error {
	// get current epoch
	val, err := s.morphClient.TestInvoke(s.contracts.netmap, getEpochMethod)
	if err != nil {
		return fmt.Errorf("can't read epoch: %w", err)
	}

	epoch, err := client.IntFromStackItem(val[0])
	if err != nil {
		return fmt.Errorf("can't parse epoch: %w", err)
	}

Instead this should be offloaded to wrappers in morph/client package. These wrappers can be created in-place in processors, so there won't be wrapper initialization section in inner ring server.

Static client methods

As for static clients, we've decided to add boolean flag if notary enalbed in static client constructors. Depending on flag, static client will call underlying client.InvokeNotary or client.Invoke methods. Static client itself (and it's wrappers) won't have two function for single contract methods invocation.