Incorrect accounts assumption for cpi

[julianzamt]

Describe the bug
Similar to #8 , when using csl_spl_token.mint_to creates code that expects an ATA, and generates code expecting the input. This is wrong in at least two ways:

1. It is possible that the user wants to use a regular token account
2. It is possible that the user wants to use an account that is already in the context. Furthermore, the accounts that will be used in a cpi may result from runtime logic execution. Assuming the inputs of a cpi, if not required, can be very confusing from a user perspective, and clutters the accounts array.

To Reproduce

methods:
  - name: mint_to_a_regular_account
    uses:
      - csl_spl_token.initialize_mint2
      - csl_spl_token.initialize_account3
      - csl_spl_token.mint_to
    inputs:
      - name: mint
        type: csl_spl_token.Mint
        solana:
          attributes: [ init ]
      - name: regular_token_account ------------> I wanted to mint to this account after creation
        type: csl_spl_token.Account
        solana:
          attributes: [ init ]

In processor, the vec of accounts that i supposedly should use in the mint_to cpi:

&vec![
	mint_info.clone(),
	assoc_token_account_info.clone(), -----> this is the account that the generator "decided" that I should mint to
	owner_info.clone(),
	wallet_info.clone(),
	token_program_info.clone(),
],

Expected behavior
To not assume which accounts are going to be used in a cpi. Even if the CIDL allows the user to map accounts to cpi methods, which accounts are going to be used may result from runtime logic.

Código CLI version:

• Version v0.8

[julianzamt]

Incorrect use of the CIDL