feat(broadcast_messages): add the Color field to BroadcastMessage

What does this MR do?

BroadcastMessage does not carry the color key, so the value GitLab returns for it is dropped on decode.

GitLab exposes it from lib/api/entities/system/broadcast_message.rb, on line 11. The exposure carries no condition, so every response built from that entity has the key: list, get, create and update alike. The value is never blank either, because the model declares attribute :color, default: '#E75E40'.

This is reproducible without credentials, because GET /broadcast_messages is a public endpoint:

curl -s https://gitlab.com/api/v4/broadcast_messages

Every one of the 20 entries gitlab.com returns today carries "color": "#E75E40", beside the "font" this library already maps.

I added the field to the create and update options as well, since both endpoints really accept it: lib/api/admin/broadcast_messages.rb declares it as an optional parameter on create, and the same file declares it on update. GitLab marks it deprecated in favour of theme, but it marks font the same way, and this library already exposes font in both option structs, so I kept the two consistent rather than treating one differently from the other.

One thing worth flagging: the Broadcast Messages API page omits color from the response examples and from both parameter tables, while still documenting font. The entity and the endpoint definitions linked above are what an instance actually serves, and the live response confirms it, so I take the page to be out of date rather than the API. I am happy to raise that as a separate documentation issue if you agree.

I found this while building gitlab-mcp-server, an MCP server that exposes GitLab through this SDK.

Is this a breaking change?

No. This adds one field to a response struct and one to each of the create and update options structs, so every existing caller still compiles and behaves exactly as before.

How was this tested?

The fixtures in broadcast_messages_test.go already contained "color": "#E75E40", and nothing asserted on it because there was no field to assert against. The four decode tests (list, get, create and update) now assert the decoded value, so a missing or misspelled json tag fails them. I checked that by temporarily renaming the tag, and all four fail as expected. I also added testBodyJSON assertions to the create and update tests, which pin the whole request body and therefore cover the new option actually being sent.

Related to #2300