lang: Consider removing associated keyword

[armaniferrante]

We should consider removing the associated keyword. I'm a little worried the automagic of adding the __nonce field will cause problems when upgrading account layouts. For example, if one were to add fields to an account, then it's possible one overwrites the __nonce field.

Instead of removing, we can also consider adding a header to the account layout to store such metadata. For example, discriminator || metadata || borsh(struct) or some variant.

Note that seeds can do everything associated can, although it requires manual nonce management/storage. So it's recommended to use seeds until the future of associated is decided.

[fanatid]

• We need to change JS api. Is it ok to left associatedAddress but change the returned value to Promise<[PublicKey, number]> or we need to create a new method?
• seed instead associated need to add b"anchor".as_ref() each time to the seed, is there any easy way to avoid it?

[armaniferrante]

• We need to change JS api. Is it ok to left associatedAddress but change the returned value to Promise<[PublicKey, number]> or we need to create a new method?
• seed instead associated need add b"anchor".as_ref() each time to the seed, should we add it magically in generated code?

• No need to create a new api. We can just remove the associated apis from the js client and use the standard PublicKey.findProgramAddress and PublicKey.createProgramAddress from @solana/web3.js.
• This isn't necessary because seeds = [<>] in the program doesn't add any seeds. Note that associated = <> added b"anchor" as a prefix to seeds for domain separation, so that seeds wouldn't conflict in the event that one accidently used both associated and seeds in the same program. If we remove associated this is no longer required. Domain separation should be done explicitly, if needed.

[suscd]

Seems fine to me to remove the associated macro.

I do think the most annoying part about using PDAs is dealing with the bump seed, which just seems awkward to pass through. I like the idea of including space for the bump seed in the account header, perhaps for all accounts since its just one byte. That way for account initialization, anchor could use findProgramAddress based on the provided seeds and store the bump inside the header, then for post-init constraint checks it could use createProgramAddress and refer back to the bump seed stored in the account header.