Simplify type names by removing redundant `executor_` prefix when context is unambiguous

[akrivx]

Description

Several public types currently repeat the owning object name (e.g. executor) even when the type is only meaningful in the context of a single API entry point or object. This adds verbosity without improving clarity and makes call sites noisier.

This issue proposes simplifying such names by removing the redundant prefix, following a Vulkan-like naming convention where the function or object already provides sufficient context.

Motivation

• The function name already disambiguates usage (e.g. texec_executor_submit)
• Shorter names improve readability at call sites
• Reduces unnecessary repetition without sacrificing clarity
• Aligns with Vulkan-style APIs (VkSubmitInfo, not VkQueueSubmitInfo)

Examples

Before

texec_executor_submit_info_t
texec_executor_diagnostics_t

After

texec_submit_info_t
texec_diagnostics_t

Guideline

If a type is only valid for a single object or API entry point, do not repeat the object name in the type. Add specificity only when real ambiguity exists.

If diagnostics or submit info types are later added for other objects (e.g. queues, schedulers), object-specific names can be introduced at that time.

Scope

• Public API
• No behavioural changes
• Mechanical rename

Benefits

• Cleaner, more readable API
• Better consistency with existing extensible *_info_t patterns
• Avoids premature over-specification