Implement SendSayMessage function and hookchain

[dystopm]

Purpose

Host_Say currently contains the full chat pipeline (sanitization + formatting + message dispatch). While it already performs important text cleanup, its monolithic design makes it difficult for modders to safely customize chat behavior (e.g., chat formats, location prefixes, alternate chat systems) via HookChains. In practice, many custom chat implementations bypass Host_Say entirely to gain flexibility, which often leads to losing the built-in sanitization and character filtering that Host_Say provides.

This PR introduces SendSayMessage as a dedicated, hookable dispatch step. The goal is to allow modders to alter chat output after it has already been sanitized by Host_Say, without re-implementing or skipping the original cleanup logic.

Approach

This change refactors the chat path by splitting Host_Say into two responsibilities:

• Host_Say retains the sanitization and safe preparation of the raw player text (character filtering, cleanup, buffer handling).
• SendSayMessage becomes the isolated “send” stage that receives the already-processed text and handles the final assembly/dispatch. This new function is exposed through HookChains so sub-plugins can adjust parameters (e.g., output formats, location text, console format) safely and consistently.

To minimize memory-safety risks in a hookable interface, SendSayMessage treats incoming string pointers as read-only and performs any required modifications (currently only truncation to protocol limits) on local bounded copies. This avoids writing into unknown buffers and prevents unsafe in-place edits that could be introduced by third-party hooks.

P.S. This PR is close to being a draft: I’d appreciate a review from a core collaborator specifically on the memory-handling aspects of the new split and the hookable surface, since small regressions in pointer/length assumptions could lead to exploitable behavior. @s1lentq

P.S.2. I’m intentionally not using REGAMEDLL_FIXES macros here, as the intended behavior should remain identical to the existing implementation; this change is meant as a refactor/extension for hookability rather than a behavioral fix or new gameplay feature.

[s1lentq]

Looks good, but I would suggest checking this on a live server for edge cases, if such an opportunity exists.
Otherwise, everything is fine.