Problems and inconsistences in lua api docs

[GlassBricks]

Hi Bilka & co, it's me again!

This has now evolved into a random list of things I've noticed are inconsistent or problematic in the lua-api docs.
Title has been updated to latest version where all these issues are still confirmed.

The following concepts don't seem to be referenced anywhere else:
- VirtualSignalId
- LogisticSections, LogisticSection, BlueprintLogisticFilter
- BurnerUsageID
- CircuitNetworkSelection Currently an completely empty table??
- RaiseEventParameters

Yes, I do have a thing doing DFS/floodfill shenanigans over things in the api docs json. The above are some unconnected components.

[GlassBricks]

More:
defines.default_icon_size is empty and unused

In SoundPath's description, the last 2 "notes" have been removed. Compare with docs for v1.1.110

In FluidIdentification, ForceIdentification, TechnologyIdentification, "Identification" has been shortened to "ID", but not for SurfaceIdentification and PlayerIdentification.

In LuaGuiElement::elem_value, ItemIdAndQualityPair can replace the generic "table" type.

[GlassBricks]

LuaPostEntityDiedEventFilter::type is specified to only be "ghost", but the variant parameter imply that type can also be `"type"`.

[GlassBricks]

[2.0.15] PipeConnectionDefinition::linked_connection_id has type uint32. But uint32 doesn't exist, it should be just uint

[GlassBricks]

[2.0.17] LuaControl set_driving takes parameters of type "bool", they should be "boolean"?
There's also a typo in that method's description. Spell checker?

[GlassBricks]

`SpacingItem` has fields with types `uint32_t` `int32_t`... did you mean uint/int?

[GlassBricks]

TechnologySlotStyleSpecification::drag_handle_style references EmptyWidgetStyle, which does not exist.

[GlassBricks]

[2.0.24]
TriggerEffect has "DamageEntityTriggerEffectItem" as a union member, but that type no longer exists (did you mean "DamagerTriggerEffectItem")?

[GlassBricks]

[2.0.39] the newly LuaSchedule::get_records, set_records, and clear_records have parameters of type "uint: interrupt_index" instead of "interrupt_index: uint".

...have you considered making a compiler to check for type errors? I guess I accidentally have

[Bilka]

...have you considered making a compiler to check for type errors? I guess I accidentally have

It errors, that's how a bunch of things you mentioned here got found and fixed independently.