Bugfix: BaseChatMesh has inconsistent use of multi-byte paths

[jourdant]

I submitted another PR (#2035) to fix a bug with auto-adverts not being published with multi-byte paths on repeaters and room servers. My original PR setup was bad, so @ripplebiz applied the patch directly to dev branch instead.

There was some code left behind in the PR that wasn't merged related to classes inheriting BaseChatMesh (Companion, Simple Secure Chat etc). The base function sendFloodScoped was defaulting to a single byte path. If this function was not overridden by subclasses, then the behaviour would persist unknowingly into those classes. In this case, only Simple Secure Chat was affected, Companion had overridden the behaviour but had the path_hash_mode + 1 convention mentioned in 5 places.

This PR introduces a new virtual helper function getPathHashSize() in the BaseChatMesh class so that all subclasses have to properly implement the multi-byte support. I have updated the subclasses to be in-line with this approach too. Hopefully it prevents any future bugs by obscurity and standardises the implementation for future subclasses too.

I'm open to commentary from community/reviewers on whether this getPathHashSize() function makes sense to be in all the firmwares, because there are 7 occurences of the path_hash_mode + 1 function being used elsewhere. At least building out the helper function reduces the risk of not being consistent across the codebase when future changes happen. Thoughts?

[jourdant]

If there is interest in generalising the helper function across the codebase (IE, for classes that don't use the BaseChatMesh class such as repeater/room/sensor), I can add another commit to this PR to standardise it all.