#24 Move ACTION and ACTIONS into the server core

[Thomas Mueller]

ACTION and ACTIONS are implemented in the IDE package (ide/GxInspect_Ide.pas, CmdAction, CmdActions), so a host program that embeds only the core (e.g. examples/VclHost) cannot execute its actions by name.

The only part that needs the IDE is how the actions are found: TryGetIdeActions asks INTAServices.ActionList. Matching the name, Update, the check for a disabled action and Execute are plain VCL, and ActnList already comes in with Controls (also in Delphi 6), so the core needs no new unit. FindIdeActionByName in the same unit is pure VCL as well: it searches all forms and data modules recursively.

What moving them needs:

• Where the core looks: without ToolsAPI there is no single list, so the core searches Screen.CustomForms and Screen.DataModules, as FindIdeActionByName does. In the IDE, ACTION then also reaches actions that are not in the INTAServices list, such as those in the IDE's DebugCommands data module, which today only the breakpoint code reaches.
• Duplicate names: a component name is unique only within its owner, and many dialogs have an action of the same name (e.g. actOK). Proposed: ACTION [<form-id>] <name>. A bare name that matches more than one action is refused with a list of where it was found, as the dispatcher does for an ambiguous command, rather than taking the first match.
• One registration only: RegisterCommand keeps a name registered from two sections as two entries, which makes the bare name ambiguous. So the core holds the only ACTION and ACTIONS, and the IDE level adds its action list through a virtual method, like GetHostDescription and PrepareQuit. That hook is probably still needed: an action added to the IDE's list without an owner is not found by searching the component trees. Whether such actions exist has not been checked.
• ACTIONS output: it would list more actions and needs to say which form or data module each belongs to. Scripts that parse it, README.md and AGENTS.md need adjusting.