Remove `@receive` decorator from compiler in favor of new `Runtime` API

[danwbyrne]

While our old handling of @receive was specific to UTXO asset receiving we still need to implement the new equivalent.

Here is a demo of what that looks like: https://github.com/neo-project/neo-devpack-dotnet/blob/4f6e384220a0e00e2171784d95896d6d2f048900/templates/Template.NEP5.CSharp/NEP5.Crowdsale.cs#L28

from line 28-48.

Basic idea is that we: 1. check the invocation counter is 1. 2. go through every notification and filter NEO/GAS transfers. 3. add up the transfers that went to the contract being called from the user calling it.

then we should have a hidden wrapper in the compiler that does this work for us when it sees the @receive decorator and gives us a helper for managing it.

Similar reimplementations might be needed for our other decorators, @send, @completeSend @claim.

[spencercorwin]

We can almost definitely remove the @receive decorator since it likely overcomplicates an API that should/would be available to every call without needing to decorate anything. So we imagine that we provide a new compiler API called "Runtime" which is similar to "Blockchain" which can then be used to access notifications in the current runtime of the function call. Look at how the C# smart contract example uses Runtime.GetNotifications() and then uses that information to find out how much was sent to the contract in the method call. That is useful for a smart contract/user to know in their method call for receiving assets. So we should provide something that abstracts that logic by just calling something like "Runtime.neoRecevied" and "Runtime.gasReceived". Under the hood we use notifications syscalls to retrieve this information.