Making the std package API more user-friendly

[leohhhn]

Description

This issue is meant to discuss potential changes to the std package API & naming. There are multiple issues/discussions on how this should happen, ie #1475 & #1521. Extracting parts of @thehowl's proposition on renaming things out of #1475 for std:

• DerivePkgAddr > AddressFromPath
• GetCallerAt > CallerAt
• GetBanker(BankerType) >NewBanker(BankerType)
• GetOrigSend > OriginSend
• CurrentRealm, PreviousRealm (instead of PrevRealm) should return the current Realm object and the previous caller (be it another realm or an EOA). This also needs to be discussed as these functions can be called in packages, and that isn't really consistent or logical naming.
• CurrentRealmPath > just use CurrentRealm.Path
• GetChainID > ChainID
• GetHeight > BlockHeight
• GetOrigCaller >OriginCaller
• GetOrigPkgAddr - the naming of this function is unintuitive - we are using the terminology "Origin Caller" to get the EOA that signed the initial transaction, but we expect the Origin Package to be the current realm/package that is having its code executed. IMHO, this should be completely removed in favor of CurrentRealm.

A broader discussion is related to if we are going to keep IsOriginCall & AssertOriginCall. These functions basically limit the caller of the transaction to be an EOA - and this blocks a lot of possible functionality, like account abstraction, smart contract wallets, & calling realms code through your code. I am personally in favor of simply removing these from the codebase.

While we are on this note, consider renaming PkgPath > Path - it is confusing that we can have packages that have package paths, but we can also have realms that have package paths ("you need to get the realm package path"). This would include making the changes in all tools as well. With this, we can also discuss renaming addpkg commands in gnokey & related tools to deploy/upload/publish.

I am not discussing the std package split as per @thehowl's comment, since AFAIK it is blocked by some other issues.

Another thing to keep in mind with these discussions is to have the std.TestXXX functions match the above, as discussed in #1521.

Please, read the other issues and put down your thoughts - this is a relatively urgent issue, since if we want to do any big renaming efforts, it would be better before we have a large dev base with a lot of apps, because the renaming would be a breaking change.

[moul]

DerivePkgAddr > AddressFromPath

"Address" and "Path" have ambiguous meanings.

Perhaps we could consider implementing something like this in Go:

type Package struct {
    Path string
}

func (p Package) Addr() std.Address {}

---

CurrentRealm, PreviousRealm (instead of PrevRealm)...

I agree to add CurrentRealm, but I prefer using PrevRealm instead of PreviousRealm. I'm open to discussing this further.

---

Everything else appears fine at the moment.

[moul]

Related with #1024