Fix how modifications work in multi-module environments (aka fix guardian shield multiple spawn)

[RkShaRkz]

While this PR set out to do one simple thing - fix how GuardianShield behaves on just one ship - the ED Shipyard Wurgandal - the problem turned out to be actually way deeper than that; not only do multi-module ships spawned GuardianShields on all of their modules, but controlling that turned out to be hard as well. Or rather - impossible.

The initial attempts tried preventing some race-conditions and whatnot by introducing synchronization mechanisms to GuardianShield and the drone spawning methods, but after some exploratory legwork it became clear that it wasn't due to the GuardianShield installed on the main module; it was from different guardian shields installed on other modules.

So, after digging deeper it became apparent that shouldAffectModule() method was in charge of both whether the modification is installable on modules and whether it's shared across all other modules. So what had to be fixed became clear, and with the newest framework extension - Modification::shouldShareEffectToOtherModules() which is now in control of everything the ExoticaTechHM hullmod does with modifications (exoticas and upgrades) on the ships/modules until an even finer-grained control becomes necessary.

However, this somewhat throws a wrench in the stuff planned to-be done in #25 as well as issue #16 as well as opening a whole new can of worms - now that this change is in place, all Exoticas and Upgrades will work only on the module where they are installed; which was not their initial behavior. This was further masked by me doing most of the testing in 'simulation' which unfortunately behaves quite differently from real combat, whereas in simulation exoticas worked for just the modules they were present on, whereas in real combat exoticas (apparently) worked on all modules of (multi-module) ships they were installed on.

So now, this PR also set out to go through all Exoticas/Upgrades and further diversify them by giving them the ability to affect all modules on a case-by-case basis; initial idea is "modifications with penalties can affect whole ship, modifications without penalties will affect only the module they were installed on" to make overpowering your ship harder. We'll see how far we'll end up straying from this idea.

[RkShaRkz]

Consider removing this https://github.com/RkShaRkz/ExoticaTechnologies/pull/26/commits/9f6de5106ef5392d33244b16d7c28d1cb4aa2843#diff-ceb08b41547ae101bd5ebf604eb3f696884bce362be6cda34dd3c38084f5f128R158-R178

(since it's been determined that shouldShareModuleEffects() doesn't quite seem to work/share for methods called in beforeShipCreation())

[RkShaRkz]

GuardianShield should inherit vanilla shield-related hullmods from host-module and install them on the shield drone (As well as do special handling in the code)

The ones i had in mind are:

• Accelerated Shields (advancedshieldemitter): +100% expansion rate
• Hardened Shields (hardenedshieldemitter): -20% shield damage from hits
• Stabilized Shields (stabilizedshieldemitter): -50% flux damage
• Extended Shields (extendedshieldemitter): +60 shield coverage doesn't make sense for 360-degree shields

[RkShaRkz]

I dont know where the comment disappeared but lemme repeat it - ~~AlphaSubcore properly decreases OP on the whole ship when installed, but when deinstalled it only reverts the OP costs on the installing module (and leaves the rest of the ship with alot of spare OP).

this branch most likely still has the problem (bad idea) of actually installing a separate subcore in every module, so that once you install 1 in the "main" module, you could pull out one from each and every module.~~

actually wait, i think all of the hullmod exoticas are broken on this branch :D i'd need to retest, but since the PR got too big, the work needed to be split.

The idea is to perfect this in #27 - which does bring significant improvements yet still fails for my ideal AlphaSubcore usecase.