

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.
"    \"confirmations\" : n,      (numeric) The number of confirmations\n"
            "    \"redeemScript\" : n        (string) The redeemScript if scriptPubKey is P2SH\n"
            "    \"spendable\" : xxx,        (bool) Whether we have the private keys to spend this output\n"
            "    \"solvable\" : xxx,         (bool) Whether we know how to spend this output, ignoring the lack of keys\n"
            "    \"desc\" : xxx,             (string, only when solvable) A descriptor for spending this output\n"
            "    \"safe\" : xxx              (bool) Whether this output is considered safe to spend. Unconfirmed transactions\n"
            "                              from outside keys and unconfirmed replacement transactions are considered unsafe\n"
            "                              and are not eligible for spending by fundrawtransaction and sendtoaddress.\n"
            "  }\n"
            "  ,...\n"
            "]\n"
            "\nExamples\n"
            + HelpExampleCli("listunspent", "")
            + HelpExampleCli("listunspent", "6 9999999 \"[\\\"1PGFqEzfmQch1gKD3ra4k18PNj3tTUUSqg\\\",\\\"1LtvqCaApEdUGFkpKMM4MstjcaL4dKg8SP\\\"]\"")
            + HelpExampleRpc("listunspent", "6, 9999999 \"[\\\"1PGFqEzfmQch1gKD3ra4k18PNj3tTUUSqg\\\",\\\"1LtvqCaApEdUGFkpKMM4MstjcaL4dKg8SP\\\"]\"")
            + HelpExampleCli("listunspent", "6 9999999 '[]' true '{ \"minimumAmount\": 0.005 }'")
            + HelpExampleRpc("listunspent", "6, 9999999, [] , true, { \"minimumAmount\": 0.005 } ")
        );
    int nMinDepth = 1;
    if (!request.params[0].isNull()) {
        RPCTypeCheckArgument(request.params[0], UniValue::VNUM);
        nMinDepth = request.params[0].get_int();
    }
    int nMaxDepth = 9999999;
    if (!request.params[1].isNull()) {
        RPCTypeCheckArgument(request.params[1], UniValue::VNUM);
        nMaxDepth = request.params[1].get_int();
    }
    std::set<CTxDestination> destinations;
    if (!request.params[2].isNull()) {