MQTT config is hardcoded to digitraffic.fi

While I was working on #64, I noticed that ship162 incorrectly passes the broker URL into the client ID of the MQTT reciever:

https://github.com/xoolive/ship162/blob/800d05a09c6f55a80ff13d3dda88e02c561f5c36/crates/ship162/src/sources/mqtt.rs#L32

which is configured with a hardcoded digitraffic broker/topic on the rs162 side:

https://github.com/xoolive/ship162/blob/800d05a09c6f55a80ff13d3dda88e02c561f5c36/crates/rs162/src/sources/mqtt.rs#L265-L267 https://github.com/xoolive/ship162/blob/800d05a09c6f55a80ff13d3dda88e02c561f5c36/crates/rs162/src/sources/mqtt.rs#L41-L42

So changing the MQTT in the config.toml actually does nothing. The readme currently recommends using mqtt = "mqtt://mqtt.digitraffic.fi", but since we cannot extract the topic/QoS from it, we will need to make a backwards-incompatible change to the config. Maybe something like:

[[sources]]
mqtt = "wss://meri.digitraffic.fi/mqtt"
client_id = "ship162-example"
topic = "vessels-v2/#"
qos = "at_least_once"

(Actually, if the MQTT is specific to digitraffic anyway maybe we can just change the config to digitraffic_client_id = "XXX", I'm not sure though)

Read crates/ship162/src/sources/mqtt.rs around line 32 and crates/rs162/src/sources/mqtt.rs around lines 41-42 and 265-267 to trace how the MQTT URL, client ID, topic, and QoS are passed. Compare this with the README configuration example. Done means configuration controls the MQTT connection in both crates without the hardcoded Digitraffic settings, with the documented configuration updated.