Fix more quic_multistream test formatting

Fix more quic_multistream test formatting

We encountered another failure in the quic_multistream_test:
https://github.com/openssl/openssl/actions/runs/14127125173/job/39578660601#step:9:1005

It appears we still occasionally get empty frames in our qlog, with the
validate-qlog.py scripts properly bails out on.  In the above case, the
offending frame entry looked like this:
{
  "name": "transport:packet_received",
  "data": {
    "header": {
      "packet_type": "initial",
      "packet_number": 4,
      "dcid": "",
      "scid": "6217813c336a012a"
    },
    "datagram_id": 6,
    "frames": [
      {
        "frame_type": "new_token",
        "token": {
          "raw": {
            "data": "44801add5794"
          }
        },
        "length": 8
      },
      {
        "frame_type": "stream",
        "stream_id": 15897,
        "offset": 625652585,
        "payload_length": 11,
        "explicit_length": true,
        "fin": true,
        "length": 8
      },
      {}    <= NOTE EMPTY FRAME HERE
    ]
  },
  "time": 0
}

I think we're still missing some frame formatting cases in
script_21_inject_plain(), which can format potentially any of the frames
listed in the forbidden_frame_types array when running the
test_dyn_frame_types test.

I think we need to enumerate all of those frame types in the case
statement we have there.  Fortunately we generally don't have to provide
sane values, and most of the cases fall into 4 categories (those that
need a 64 bit data value, and those that require 1, 2 or 3 variable
integers).  There are two special cases, NEW_TOKEN, and NEW_CONNECTION,
but those just need a mix of fixed and variable width data.

So lets fully enumerate those and hopefully put this to bed.

Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/27200)