Just find&replace, no code changes. This is prepwork for making the GenericDocument editable. Also 'Reader' commonly refers to the text file parser, so this should be clearer.

MANIP_ enum fields got renamed to ASMANIP_ to match C++ with AngelScript.
Doxygen docs were added.
Manip type 'UNLOADED' got renamed to 'UNLOADING' to signify it's delivered to all scripts, even the one to be unloaded.

For a demo, type `loadscript example_GenericDoc_editor.as` to the ingame console. Then follow instructions on the menu bar.

I've wanted to do this for a long time. In all prior versions, you must be in menu to update modcache, and it's synchronous (loading dialog). The single (stupid!) reason for this is that CacheEntry-ies are kept in a plan std::vector<CacheEntry> and actors have raw pointers to them (updating std::vector breaks raw pointers). If a cache entry was a RefCountingObject<>, we could simply flag them 'deleted' and insert new ones on-the-go, even in simulation. RepoUI could be used anytime. Minimum dev work, fantastic implications.

`MSG_EDI_CREATE_PROJECT_REQUESTED` creates subdirectory in 'My Games\Rigs of Rods\projects', pre-populates it with files and adds modcache entry.

New AngelScript API: global object `cache` of type CacheSystemClass, enum LoaderType for filtering when searching, class `CacheEntryClass`.

See updated 'example_GenericDoc_editor.as' which uses both the new modcache API and the recently added GenericDocument editing API.

* Second thought: CacheSystemClass global object is now `modcache`
* ModCache regen now picks up the 'projects' directory
* example_GenericDoc_editor.as now fixes up the project categoryID to 8990

New script API:
* New ✉️ MSG_EDI_LOAD_BUNDLE_REQUESTED
* New ✉️ MSG_EDI_UNLOAD_BUNDLE_REQUESTED
* added script event `SE_GENERIC_MODCACHE_ACTIVITY`
* added enum `modCacheActivityType` with fields _ADDED, _DELETED, _LOADED, _RELOADED, _UNLOADED
* added function `modcache.getEntryByNumber(int)`
* added function `modcache.query()` which takes a dictionary resembling `RoR::CacheQuery` and returns a dictionary with results.
   Query dictionary params:�    - "search_expr" - searchstring, recognizes all advanced modes from MainSelectorUI like "author"
    - "filter_guid" - filter by exact match on GUID, used for skins/missions(WIP)/addonparts(WIP)
    - "filter_category_id" - filter by category. Special category Projects is 8990.
   Result dictionary params:
    - "count" (int64)
    - "entries" (array<CacheEntry@>)
    - "scores" (array<uint>)

Codechanges:
* GameScript::GetValueFromDict() was moved to ScriptUtils.h as `GetValueFromScriptDict()`
* fixed bug in ScriptEngine methods unloadScript(), getScriptUnit(), scriptUnitExists() - when called with SCRIPTUNITID_INVALID, this value would get inserted as key to `m_script_units`.

Headers should make do with forward decls and shouldn't `#include Actor.h` at all.
This means no code (function body or even autogenerated ctor/dtor) which manipulates ActorPtr should be in header.

STATUS: ALPHA! Glitchy, only adding a part works, the remove-button is dummy.

This adds a new mod type "addonpart" (file pattern *.addonpart) which works as a partial truck file - when selected, it adds additional elements to it. Currently supported features are: managedmaterials, props, flexbodies. The point is to automate what users had to do manually before: https://docs.rigsofrods.org/tools-tutorials/addons/

The addon parts receive all usual treatment from modcache: they can have preview images, name + description are always displayed, they can be searched for, the MainSelectorUI can be opened in mode 'LT_AddonPart' to show only addon parts. In addition, the search can be filtered by a vehicle GUID, much like with SkinZips. This is an example addonpart (port of https://forum.rigsofrods.org/resources/heavy-bumper-for-the-chevy-k3500.461/):

```
addonpart_name "Heavy Bumper for the Chevy K3500 (Prop, Black)"
addonpart_description "For use with GMT400 88-98 Chevy Truck Pack"

;addonpart_guid <guid>  ~ multiple GUIDs can be specified
addonpart_guid 057b21c8-cb54-496d-88ce-4855a8d6d43d
; * 1990 Chevy 454ss,  * 1990 Chevy k3500    * 1990 Chevy K3500HD
addonpart_guid 6a53ad83-255d-4d5e-bf14-ca0714e5228d
; * 1990 Chevy k2500 Blazer, -SAS, -Suburban

managedmaterials
    CHeavyBumper		mesh_standard		HeavyBumper.dds		HeavyBumper_s.dds

props
    39, 62, 34,    0.50,    0.32,     -0.5,   0,    180,    180, CHeavyBumper.mesh
```

There's a new menu in TopMenubarUI: "Tuning". It lists already installed addonparts and contains [add parts] button which opens MainSelectorUI in 'LT_AddonPart' mode, with GUID filtering for the current vehicle.

To remember what addonparts user selected, an additional mod type was added: "tuneup" (file pattern *.tuneup) - this works like ".skin for addonparts" and has intentionally similar syntax. There are 2 power tools:
* "use_addonpart <filename>" to install an addonpart on the vehicle (multiple can be used!)
* "remove_prop <meshname>" to strip an existing prop from the vehicle.

Note: An option to replace prop was intentionally not implemented because that would be a duplicate feature with addonparts. It's up to user to remove props if and only if they don't want them together with new parts.

When user uses addonpart with a vehicle for the first time, the game creates a .tuneup file for it  in {Documents\My Games\Rigs of Rods\projects\}. When spawning the vehicle next time, the .tuneup is loaded automatically. In the future the menu will be able to save custom tuneups. Here's an example:

```
Tuned 1990 Chevy 454ss
{
      use_addonpart = CHeavyBumperBlackProp.addonpart
	preview =
	description =
	author_name = ohlidalp
	author_id = -1
	category_id = 8100
	guid = 057b21c8-cb54-496d-88ce-4855a8d6d43d
}
```

Under the hood, applying the addonparts to the vehicle works entirely in system memory, no truck files are modified or written.
* "use_addonpart" works by literally introducing a fake 'section/end_section' to the truck file parsed in memory - see `class RigDef::File::Module` and function `ActorSpawner::ConfigureAddonParts()` for details.
* "remove_prop" works as last-minute check in `ActorSpawner::ProcessProp()`, skipping props which are blacklisted.

This EDI message now hosts all tuneup edits. See enum `ModifyProjectRequestType` in CacheSystem.h.
The ActorModifyRequest types INSTALL/REMOVE_ADDONPART_AND_RELOAD were replaced by ModifyProjectRequest types TUNEUP_USE_ADDONPART_SET/RESET.
The TopMenubar/Tuning UI now has list of props with checkboxes to toggle them. The toggle immediatelly modifies the tuneup and respawns the actor.
All tuneup edit types are handled by `CacheSystem::ModifyProject()`. The code was moved from `GameContext::ModifyActor()`;

The .addonpart file can now specify "unwanted" props or flexbodies, to simulate swapping of parts. Under the hood, this works by adding the mesh names to "remove" lists, same as if user disabled them from top menu. Example addonpart:

```
  ; Add the stock bumpers to 'tuneup.removed_flexbodies' unless user added it to 'tuneup.protected_flexbodies' first.
  addonpart_unwanted_flexbody "K3500_FBump.mesh"
  addonpart_unwanted_flexbody "454ss_FBump.mesh"�```�
The .tuneup file now contains lists of "protected" props and flexbodies which cannot be removed by the addonpart and remain "removed" or not as the user wishes. This lets user force default meshes to be kept or addonpart meshes to not be added (may be useful if the addonpart specifies multiple meshes). Example of protected entry in .tuneup file:

```
	protected_flexbody = 454ss_FBump.mesh
	protected_flexbody = K3500_FBump.mesh
```

There are 2 new directives in the addonpart format:
* `addonpart_tweak_node <nodenum> <posX> <posY> <posZ>`
* `addonpart_tweak_wheel <wheel ID> <rim mesh> <tire radius> <rim radius>`

Changed addonpart syntax: 'addonpart_tweak_wheel <wheel ID> <media1> <media2> <side flag> <tire radius> <rim radius>'
media1 = required ('wheels[2]': face material, 'meshwheels[2]/flexbodywheels': rim mesh)
media2 = optional ('wheels[2]': band material, 'meshwheels[2]/flexbodywheels': tire material)

Known glitch: when you enable and then disable the addonpart with custom meshwheel2 rims, they still show up but in bright magenta (managedmaterials error indicator color).

Code changes:
* Added `WheelID_t` to ForwardDeclarations.h, using everywhere in ActorSpawner.cpp
* AddonPartFileFormat.cpp - parse new format
* TuneupFileFormat.cpp - separate media 1/2 funcs unified; added `getTweakedWheelMediaRG()`

Feature changes:
* .tuneup file format: To make things consistent, I changed the removed/protected system of props and flexbodies to use IDs (depending on order of definition in truckfile) rather than mesh names, as those can be ambiguous (used more than once) and wheels cannot use this approach at all. This is a backwards-incompatible change to the .tuneup format.
* Because some special props (dashboard, beacon) can have extra resource (dirwheel mesh / beaconflare mat), I used the same "Media 1&2" system like in wheels.
* I fixed the bug from previous commit where the prop/flexbody checkbox would have no effect (the vehicle would reload but the checkbox would revert) until you checked the "protected" mini-checkbox first. Now the big checkbox also automatically checks the small checkbox, to stop evaluating addonparts for the element (which would undo user's selection).
* Actor spawning: I changed how game treats props/flexbodies disabled via tuneup/addonpart: instead of leaving them out, they're now kept as placehoders without media loaded. This simplifies Tuning UI and traversal.
* Flexbodywheels: Instead of generating whole meshwheel (with tire submesh made transparent by "track/trans"), only a separate rim mesh is loaded. This should improve FPS and also declutter the code.

Code changes:
* GameContext.cpp - fixed debug assert when using `ChainMessage()` without doing `PushMessage()` first.
* ForwardDeclarations.h - added `WheelID_t` and `FlexbodyID_t` for clarity. Consistent with node ID system (and other element system in dev branches).
* GfxData.h - struct Prop - added ID and media 1+2, also codedoc about tuneup/addonpart modifications.
* GUI_TopMenubar: Added IDs to the prop/flexbody listings. Updated the prop/flexbody checkboxes to also set "protected" state.
* GUI_FlexbodyDebug: fixed crash on meshes disabled via tuneup/addonpart.
* ActorSpawner: All `XXXWheelVisuals()` builder functions updted to handle tweaked params. I no longer pass the "def" objects around, just the individual params.
* ActorSpawner.cpp: added tweak support. Shortened node lookup code by using `GetNodeIndexOrThrow()`. Added placeholders for props/flexbodies removed by tuneup. `CreateFlexBodyWheelVisuals()` no longer calls `BuildMeshWheelVisuals()` but creates the rim entity itself and simply omits the "track/trans"-ized tire submesh.
* FlexBody: updated to accept tweaked parameters and to be able to exist as placeholder without geometry loaded.
* FlexFactory: updated to accept tweaked parameters
* Tuneup file format: added structs TuneupPropTweak and TuneupFlexbodyTweak. "protected" and "removed" arrays now use IDs (int) instead of mesh names (string). Added lots of new `getTweakedXXX()` helpers
* AddonPartFileFormat: fixed `ResetUnwantedAndTweakedElements()` not respecting the "protected" state. "protected" and "removed" arrays now use IDs (int) instead of mesh names (string).

Code changes:
* TuneupFileFormat: just renamed `Xrot` to `Xrotation`
* CacheSystem.cpp: Fixed protected elements not being reset with Reset btn.
* AddonPartFileFormat: Fixed `addonpart_tweak_prop/_flexbody` not being parsed at all.
* FlexBody, FlexFactory: added 'orig mesh name' field to flexbody, for UIs.
* ActorSpawner: Pass ID and orig mesh name to placeholder-flexbody.
* GfxActor: fixed crash when rendering actor with a flexbody removed via tuneup/addonpart. The problem was `FinishFlexbodyTasks()` processing placeholder flexbodies. Now using `isVisible()`.

Codechanges:
* enum `WheelSide` moved from RigDef_File.h (namespace RigDef) to GfxData.h (namespace RoR)
* GfxActor.cpp - SetWheelsVisible() - removed redundant code, rim entity visibility is already handed in FlexMeshWheel::setVisible()
* GfxData.h - added wheel ID, side and redundant mesh name to struct WheelGfx
* GUI_TopMenubar.cpp - fixed prop/flexbody counts, added wheels code.
* ActorSpawner: Unified all wheel-visual setup func names to Create*, always passing wheel side as WheelSide. In `CreateFlexBodyWheelVisuals()`, reverted code to use CreateMeshWheelVisuals() again as the setup was incomplete and the rim wouldn't be updated at all.
* CacheSystem: added FORCED_WHEEL_SET/RESET actions to ModifyProjectRequest.
* TuneupFileFormat: fixed `getTweakedWheelSide()` not querying the UI overrides.

* GUIUtils.cpp - fixed ImButtonHoldToConfirm() not reacting to first press in game session.
* GUI_TopMenubar.cpp - fixed crash when tuning is disabled
* FlexBody.cpp - fixed crash hazzard when flexbody is removed via UI or AddonPar - reported by Mike on Discord.
* AddonPartFileFormat.cpp - reset tweak data every time - fixes Reload button (under addonparts section) having no effect.
* CacheSystem - properly unload all cached documents (skin/truckfile/addonpart) when reloading cache entry.
* TuneupFileFormat.h - codedoc
* TuneupFileFormat.cpp - fixed 'wheel_forced_side' not saved to/loaded from .tuneup file.

All the UI overrides are now separate from any addonpart changes (tweaks or 'unwanted_*'). The 'protected' checkbox on the right just blocks addonpart changes, but isn't necessary for the UI overrides anymore. When you make an UI override, the respective widget will be outlined orange and a 'reset' button will be drawn. Internally, the UI overrides are called "force_*something*".

CAUTION: Top menubar Tuning menu is only corrected for flexbodies, not props yet!

Codechanges:
* TuneupFileFormat.h: replaced shared 'remove_props/flexbodies' by dual 'unwanted_*' and 'force_remove_*'. Added helper funcs.
* TuneupFileFormat.cpp: Updated parsing + exporting code.
* CacheSystem.h: `enum ModifyProjectRequestType`: REMOVE fields renamed to FORCEREMOVE. `struct ModifyProjectRequest`: removed hacky field `mpr_subject_set_protected`. Added func `LoadSupplementaryDocuments()`
* CacheSystem.cpp: updated and cleaned up `ModifyProject()` as the `mpr_subject_set_protected` hack isn't needed anymore.
* AddonPartFileFormat.cpp: updated to set/reset `unwanted_` fields - cleaner.
* GUI_TopMenubar.cpp - updated UI to signify overrided elements.

codechanges:
* GUI_TopMenubar.h: new function `DrawTuningForceRemoveControls()` - helper for both props and flexbodies.
* GUI_TopMenubar.cpp - use `DrawTuningForceRemoveControls()` for both props and flexbodies.
* ActorSpawner.cpp - renamed func.
* TuneupFileFormat.h - nicer doxy groups, renamed `isFooRemoved()` to `isFooAnyhowRemoved()` because it now looks at both 'unwanted_' and 'force_removed'
* TuneupFileFormat.cpp - isFooAnyhowRemoved()` funcs updated to look at both 'unwanted_' and 'force_removed'

I give up on understanding why the offset and rotation works differently now...

Reported by CuriousMike: "load map, spawn any vehicle, go back to main menu, click settings -> general -> update cache".

Fixed by introducing a rule "we just always load subdirs as 'writable', even during modcache update."

an older bug that Mike reported and I didn't note down: "if the last character in .addonpart file isn't a whitespace (space, tab or linebreak), the last token is skipped. For example, if last line is `addonpart_tweak_wheel 3 "myfacemat" "" n 0.2`, the custom facemat applies but the radius '0.2' doesn't."

I fixed the 'addonpart_tweak_wheel tire radius won't apply if rim radius value is missing' bug

Problem: if addonpart defines new prop or flexbody, the meshes are still searched in the mod's resource group. This is because the new elements are added as extra 'section' (Module) to the RigDef::Document so they're treated as any other.

Solution: add a `_mesh_rg_override` string field to RigDef::Prop/Flexbody (in RigDef_File.h) and make ActorSpawner respect it.

`Parser::ProcessForsetLine()` puts the node ranges to `node_list_to_import`. Normally `SequentialImporter::ResolveFlexbodyForset()` handles the resolution but that only works when parsing the actual truckfile, not when programmatically injecting further elements.

… GUIDs.

This required an internal overhaul as the 'working tuneup' is no longer a CacheEntry (common to all instances of the given mod), but an individual TuneupDef instance (specific to each spawned actor).

SIGNIFFICANT CODE CHANGES:
* Actor.h - Replaced `CacheEntryPtr     m_used_tuneup_entry;` with `TuneupDefPtr      m_working_tuneup_def;`
* TuneupFileFormat: added `isFooTweaked()` helpers (where Foo is Prop/Wheel etc...) used by all specific `getTweaked*()` helpers.
* Savegame.cpp - Added a "tuneup_document" field to actor entries, carrying the entire .tuneup file content.
* CacheSystem: only user-saved tuneups are now placed to modcache, the working tuneups are just in memory.

Problem1 = .tuneup with empty name-line breaks parsing. Fixed in Actor.cpp
Problem2 = the addonpart bundles didn't get always loaded. Fixed in ActorSpawner.cpp

Added tracking of active button ID - that way multiple buttons on same window don't interfere by resetting it's timer.

When disabled, the Tuning menu in TopMenubar UI doesn't appear at all and any attempt to use a tuneup (via scripting or in savegame) will be ignored.

…ked string).

Caused by a copypaste derp.

Problem: Initially the TuneupDef object was always present, but in recent commits it's just created when actually applying some tuning. The saving logic was not updated, though, so saving early caused crash.

Fix: The UI was updated to only show the [SaveAs...] button when the TuneupDef already exists.
UI improvement: the [Reset] button now removes the TuneupDef object instead of just resetting it, so the UI returns to initial state, clearly indicating there are no changes to be saved anymore.