Feature Request: Ability for Mergemods to update entire (non-vanilla) classes

[Tajfun403]

The issue: As of this moment, performing an update to a class which was added to a startup file by a mod is not perfectly comfortable. A new custom class can be very simply pulled into a startup file by utilizing assetupdate and canmergeasnew properties of a mergemod. However, it cannot be updated in the same easy method anymore: assetupdate would only update the main class export, leaving out updates committed to existing functions (because their exports already exist - so they won't be merged in again). This proves releasing further updates to end users difficult.

Current alternatives:

• Asking end users to vanilla the impacted pcc files before telling them to install the mod again adds a large amount of steps that heavily complicate the mod install. It can also mean the users might need to reinstall a large amount of other mods just to update this single one properly.
• Instead of relying on assetupdate, new updates to every single function could be distributed as separate addtoclassorreplace statements. This however makes the setup required for each update significant, and in case a lot of code was modified, it could quickly escalate into a prohibitive amount of statements.

Solutions:

• It would be beneficial to introduce an option which would allow one to trash existing entries of a class and all its children, before merging in its content anew.
• Another solution would be to make sure all entries referenced by the merged-in assets will be pulled anew, instead of the current functionality where they are only pulled in if they were not already present in the file. This would make it additionally beneficial in case the class also supplied external new objects - such as textures - as those could be easily updated as well with a single assetupdate, rather than through several for each entry.
• Another another solution, as proposed by @Mgamerz, would be to allow replacement of entire classes through scriptupdate, as long as it is a non-vanilla class. As discussed over discord here, 2023-08-23: Additionally, this option would also allow one to effectively clear a class (by scriptupdating it with an empty stub), achieving same possibilities as in the first proposed solution.