implement TestPublicKey util and refactor examples

[harrysolovay]

Closes #1516

In addition to solving the false positive / unchecked indexing error of the local blockchain's testAccounts, this PR introduces TestPublicKey, a subclass of PublicKey off of which key (the corresponding PrivateKey) can be accessed. This leads to a reduction in test code boilerplate, as one doesn't need to define the corresponding private key under its own name.

- let feePayerPrivateKey = Local.testAccounts[0]?.privateKey!;
- let feePayerPublicKey = Local.testAccounts[0]?.publicKey!;
+ let [feePayer] = Local.testAccounts

// ...

- await Mina.transaction(feePayerPublicKey, () => {
+ await Mina.transaction(feePayer, () => {
    // ...
- }).sign(feePayerPrivateKey)
+ }).sign(feePayer.key)

For cases in which a non-pre-funded account is needed (for instance, to be used as a contract account), one can use TestPublicKey.random.

const a = Mina.TestPublicKey.random()
a // `TestPublicKey`

const [b, c] = Mina.TestPublicKey.random(2)
b // `TestPublicKey`
c // `TestPublicKey`

---

Note to reviewers re. naming convention: I addressed some (but not all) of the test naming inconsistencies (#1578).

[mitschabaude]

This is great!

Re naming, "account" for a public key (with attached private key) feels not optimal, there is the distinct concept of an account. So it should stay at "public key" or "address"

[harrysolovay]

Re naming, "account" for a public key (with attached private key) feels not optimal

Can you please add your thoughts in #1578 and I'll fix all occurrences in a follow-up PR?

[mitschabaude]

@harrysolovay I just realized that this takes 2ms per public key (it does an elliptic curve scaling), so 200ms for 100 accounts feels a bit excessive to do every time we instantiate local blockchain.

Maybe we can create these test accounts lazily and still preserve the same API with some trickery. If not, I'd prefer to create only 20 or so.

All of this can be a separate PR