Sequence points for some of RET statements are improperly generated

[AnnaShaleva]

Current Behavior

For some RET instructions our compiler generates sequence points with improper boundaries, for example for void functions (if there's no explicit return keyword in the code), also for functions with named parameters where explicit return keyword is missing and may be for more cases that I'm not aware of (it needs to be investigated). The example of such function is given here: #3559 (comment).

Improper boundaries of such sequence points include the whole function body, like it's described here: #3617 (comment)

One case is caused by this code (but there are probably more cases):

neo-go/pkg/compiler/codegen.go

Lines 542 to 543 in 86ed214

	c.saveSequencePoint(decl.Body)
	emit.Opcodes(c.prog.BinWriter, opcode.RET)

This behaviour is invalid, because:

1. There are some return statements that have proper boundaries of sequence points. For example, non-void functions where return keyword is explicitly present. It's because return keyword is properly handled by our compiler and sequence point is generated only for the return AST node:
   

   neo-go/pkg/compiler/codegen.go

   Line 755 in 14ea5a8

   case *ast.ReturnStmt:

   
   

   neo-go/pkg/compiler/codegen.go

   Line 793 in 14ea5a8

   c.saveSequencePoint(n)

2. C# compiler properly handles the described case and generates RET sequence points with short-range. Although it has slightly different behaviour in that it bounds RET opcodes to closing brackets of the corresponding functions (}). This behaviour is described here: neotest: exclude RET statements from coverage #3617 (comment)

Expected Behavior

Boundaries of all sequence points corresponding to RET opcodes must not have function-wide bounds.

Possible Solution

Rework the way how sequence points generated for RET opcodes. At least fix these "function-wide" sequence points. May be rework the whole scheme of RET sequence points generation to make the behaviour similar to C# compiler.

Additional context

Related to #3559 and #3617.