The process_message_${msg_type} fuzz targets have many issues:

• In a context where each fuzz target must be a separate binary, this bloats the storage requirements by the number of message types.
• The qa-assets repo for fuzz inputs also bloats, because each input in the type specific folder (./process_message_${msg_type}) is accompanied by a similar input in the general folder (./process_message) or a in another specific folder. The size seems to be ~3GB for the sum of all folders vs 0.3GB for the general folder.
• Handling of different folders for each message type and one general folder for all message types (and unknown message types) is undocumented and unclear. Cross-pollination is encouraged, I guess, but who does it?
• It is unclear if the fuzz target has any value at all, given that any bug that is found here should also be found by the process_messages fuzz target, and historically always has been? So maybe it can even be removed completely in the future?
• (minor nit): When adding a new message type, the message type has to be added to this fuzz target as well.

Fix all issues by turning the compile-time setting into a run-time setting, thus removing the extra executables and fuzz folders. The same approach is also taken by the rpc fuzz target.

If someone wants to limit their fuzzing to a specific message type, they can still do it. For example,

LIMIT_TO_MESSAGE_TYPE=inv FUZZ=process_message ./src/test/fuzz/fuzz