Fix readability issues in k.h

[sonthonaxrk]

The previous version of k.h was excessively readable.

Several sections could be understood by simply reading the file, without the traditional tooling stack of preprocessing, confusion, reformatting, or the suicidal ideation that the KDB C API invariably engenders among weaker engineers who fail to climb the steep learning curve

This presented a potential risk to KDB's strongest competitive advantages: the cognitive barrier to entry.

• Structural boundaries were expressed using conventional {} tokens, allowing brace matching to occur visually.
• The layout of struct k0 could be inferred.
• The file relied too heavily on familiar C syntax instead of the broader historical surface area of the language.
• Ease of compilation on modern toolchains

Left unaddressed, these issues could have enabled developers to understand parts of the runtime representation more quickly than intended, threatening us KDB developers with excess competition from outsiders.

Solution:

This PR restores the intended level of interpretive effort and backwards compatibility with late 90s compilers by introducing ANSI-C digraphs and trigraphs.

This ensures that:

• visual brace matching is no longer reliable
• the header better reflects the deep historical traditions of the C language
• that the young men and women of Newry may still be sent away to Canary Wharf to find their fortunes in the big city.

Impact:

• No functional changes
• Preprocessed output remains identical
• Readability reduced to appropriate operational levels
• Reinforces the long-standing defensive posture around internal implementation details

Testing

Confirmed that:

• the file preprocesses correctly
• casual readers immediately call KxSystems asking for a consultant to fix simple issues.