Proposal for Carrot Transaction Format Changes
Carrot will require either a change to the hard format of `cryptonote::transaction_prefix` or a change to `extra` field handling.

### What transaction data Carrot needs

#### Per transaction output

| Name | Symbol | Byte Size |  Same storage as v16 |
|---------|------------|--------------|-------------------------------|
| Output pubkey | <code>K<sub>o</sub></code> | 32 | Yes |
| Amount commitment | <code>C<sub>a</sub></code> | 32 | Yes |
| Encrypted amount | <code>a<sub>enc</sub></code> | 8 |  Yes |
| Encrypted Janus anchor | <code>anchor<sub>enc</sub></code> | 16 | No |
| View tag                | `vt` | 3 | No |

Note that Carrot expands the per-output size of enotes by 18 bytes from 73 to 91. 

#### Enote ephemeral pubkeys

Carrot transactions, like the previous addressing protocol, needs "enote ephemeral pubkeys" AKA "additional transaction pubkeys" to act as bases for the ECDH sender-receiver secret. There is one enote ephemeral pubkey <code>D<sub>e</sub></code> per transaction output, except in non-coinbase 2-output transactions, where there is only one total. This is more or less the same as before, as the wallet construction/scanning code already did the 1-transfer-1-change transaction pubkey optimization. 

### How we could store this data 

The most straight-forward way to store the per-output data would be to add the non-amount stuff to a struct like so:
```
struct txout_to_carrot_key
{
    crypto::public_key key;
    carrot::janus_anchor_t janus_anchor;
    carrot::view_tag_t view_tag;
};
```

And then add it to the `txout_target_v` variant, just like how the v15 view tag update did it. We would keep the amount commitments in `outPk` and encrypted amounts in `ecdhInfo`, just like they currently are. That way, both coinbase and non-coinbase transactions' output targets would be `txout_to_carrot_key`, just like how it is now with `txout_to_tagged_key`. 

As for the enote ephemeral pubkeys, there's two main possible pathways we could take: A) put it in `extra` like how transaction pubkeys are done now, or B) hardcode it into the transaction format. Option A has much easier integration. Option B will be able to save one byte per transaction by skipping the size, since the number of enote ephemeral pubkeys is a direct function of the number of outputs and whether or not the transaction is coinbase. I vote option A since FCMP++/Carrot will add a lot of changes to the format already without new premature optimizations. 