[Aptos Framework][Coin] Switch to an explicit opt-out model for coin transfers

[movekevin]

Description

Context:
Currently, in many cases, coins (ERC-20 tokens, including APT) cannot be sent directly to an account if:

• The account has not been created. aptos_account::transfer or account::create_account needs to be called by another account that can pay for gas. This is generally a slight annoyance but not too big of a pain.
• The account has not registered to receive that coin type. This has to be done for every custom coin (APT is registered by default when creating an account). This is the main cause of complaints/pain.

Proposed solution:
Switch over to an explicit opt-out model. By default, an account can receive transfers of coins they have not registered via aptos_account::transfer_coins. They can explicitly opt-out any time via aptos_account:: set_allow_direct_coin_transfers

Test Plan

Unit tests

[0xchloe]

nit: should we call this function by a more explicit name? smth like transfer_to_existing_or_nonexisting_account - this does sound way more verbose than transfer, but think transfer is a simple name that people might mis-use

[movekevin]

That's really verbose. I'm not sure how people would misuse transfer here as it's meant to implicitly create an account (and may be register the coin type) if one doesn't exist yet. As proposed (I'll create an AIP soon), this new flow/function should be the default to use so users wouldn't need to worry about the nuances of accounts and coin registration.

[0xchloe]

yeah I don't feel strong about this, just thought that some devs might use the transfer function here as the default transfer function without realizing that they could be transferring coins to an account that doesn't exist yet. as long as we make it clear, sgtm

[github-actions]

✅ Forge suite land_blocking success on 7089c7be63f5f7043a941356438c6213fa00b94b

performance benchmark with full nodes : 6046 TPS, 6554 ms latency, 12700 ms p99 latency,(!) expired 20 out of 2581900 txns
Test Ok

• Grafana dashboard
• Humio Logs
• Test runner output
• Test run is land-blocking

[github-actions]

✅ Forge suite compat success on testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b ==> 7089c7be63f5f7043a941356438c6213fa00b94b

Compatibility test results for testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b ==> 7089c7be63f5f7043a941356438c6213fa00b94b (PR)
1. Check liveness of validators at old version: testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b
compatibility::simple-validator-upgrade::liveness-check : 7186 TPS, 5402 ms latency, 7300 ms p99 latency,no expired txns
2. Upgrading first Validator to new version: 7089c7be63f5f7043a941356438c6213fa00b94b
compatibility::simple-validator-upgrade::single-validator-upgrade : 4266 TPS, 9542 ms latency, 12600 ms p99 latency,no expired txns
3. Upgrading rest of first batch to new version: 7089c7be63f5f7043a941356438c6213fa00b94b
compatibility::simple-validator-upgrade::half-validator-upgrade : 4455 TPS, 9141 ms latency, 11500 ms p99 latency,no expired txns
4. upgrading second batch to new version: 7089c7be63f5f7043a941356438c6213fa00b94b
compatibility::simple-validator-upgrade::rest-validator-upgrade : 6366 TPS, 6190 ms latency, 10900 ms p99 latency,no expired txns
5. check swarm health
Compatibility test for testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b ==> 7089c7be63f5f7043a941356438c6213fa00b94b passed
Test Ok

• Grafana dashboard
• Humio Logs
• Test runner output
• Test run is land-blocking