

Using bitcoin-cli in order to generate a transaction with two op_return generate a wrong transaction.

```
bitcoin-cli createrawtransaction "[]" "{\"data\":\"ee\", \"data\":\"ff\"}"
0200000000020000000000000000036a01ee0000000000000000036a01ee00000000
```

Decoding the hex I obtain the following transaction with two op_return with the same value.

```
bitcoin-cli decoderawtransaction "0200000000020000000000000000036a01ee0000000000000000036a01ee00000000"
{
  "txid": "ed4b691958a573c8569177606c77905ecd07c36eb5eec443f17a45427bb9f5fc",
  "hash": "ed4b691958a573c8569177606c77905ecd07c36eb5eec443f17a45427bb9f5fc",
  "version": 2,
  "size": 34,
  "vsize": 34,
  "weight": 136,
  "locktime": 0,
  "vin": [
  ],
  "vout": [
    {
      "value": 0.00000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_RETURN -110",
        "hex": "6a01ee",
        "type": "nulldata"
      }
    },
    {
      "value": 0.00000000,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_RETURN -110",
        "hex": "6a01ee",
        "type": "nulldata"
      }
    }
  ]
}
```

This incorrect behavior is related to the duplicate key "data" in the JSON passed to the "createrawtransaction" command.

The problem is related to the use of `outputs[name_].getValStr()` in an JSON with duplicated keys https://github.com/bitcoin/bitcoin/blob/master/src/rpc/rawtransaction.cpp#L432

Although this kind of transaction wouldn't be relayed, I thought about two possible solutions:
* raise an error as it happens for the use of two identical addresses, maybe calling `JSONRPCError(RPC_INVALID_PARAMETER ...` if more than one "data" field is recognized - easier to implement, 
* creation of the transaction correctly containing the two different op_returns, maybe need to pass one array in the data field of the passed JSON (like `"data": ["ee", "ff"]`) - maybe require API change.
if (!DecodeHexTx(mtx, request.params[0].get_str(), true)) {
        throw JSONRPCError(RPC_DESERIALIZATION_ERROR, "TX decode failed");
    }
    
    auto locked_chain = pwallet->chain().lock();
    LOCK(pwallet->cs_wallet);
    EnsureWalletIsUnlocked(pwallet);
    return SignTransaction(pwallet->chain(), mtx, request.params[1], pwallet, false, request.params[2]);
}
static UniValue bumpfee(const JSONRPCRequest& request)
{
    std::shared_ptr<CWallet> const wallet = GetWalletForJSONRPCRequest(request);
    CWallet* const pwallet = wallet.get();
    if (!EnsureWalletIsAvailable(pwallet, request.fHelp))
        return NullUniValue;
    if (request.fHelp || request.params.size() < 1 || request.params.size() > 2) {
        throw std::runtime_error(
            RPCHelpMan{"bumpfee",
                "\nBumps the fee of an opt-in-RBF transaction T, replacing it with a new transaction B.\n"
                "An opt-in RBF transaction with the given txid must be in the wallet.\n"
                "The command will pay the additional fee by decreasing (or perhaps removing) its change output.\n"
                "If the change output is not big enough to cover the increased fee, the command will currently fail\n"
                "instead of adding new inputs to compensate. (A future implementation could improve this.)\n"
                "The command will fail if the wallet or mempool contains a transaction that spends one of T's outputs.\n"
                "By default, the new fee will be calculated automatically using estimatesmartfee.\n"
                "The user can specify a confirmation target for estimatesmartfee.\n"
                "Alternatively, the user can specify totalFee, or use RPC settxfee to set a higher fee rate.\n"
                "At a minimum, the new fee rate must be high enough to pay an additional new relay fee (incrementalfee\n"
                "returned by getnetworkinfo) to enter the node's mempool.\n",
                {