Implement #4397, Internal Bomb Bay quirk, plus various fixes and improvements

[Sleet01]

This has some pretty big changes:

New gameplay features:

1. Aerospace fighters, Conventional Fighters, Fixed Wing Support aircraft, Small Craft, and Dropships with the "Internal Bomb Bay" quirk can now mount bomb-type munitions internally. The Bombs section of the configuration dialog will indicate Internal and/or External bomb options as appropriate. When bombing, the user will be prompted separately for Internal and External bomb stores to utilize (this is necessary for accounting reasons, and to keep the UI simple).
2. Units that utilize their internal stores to make attacks (or to TAG, if a TAG pod is mounted) chance ground fire touching off any other stores in their internal bays: on a 10+ roll at the end of a round in which a unit has taken damage from ground fire, all remaining internal bombs explode, dealing their full damage directly to SI!

Changes/Additions

1. Re-organized Aero class hierarchy slightly:

|Entity
|- Aero
    |- TeleMissile
    |- AeroSpaceFighter                 // Inserted between Aero and subclasses
    |   |- ConventionalFighter
    |   |   |- FixedWingSupport
    |   |- FighterSquadron             // Now made up of ASFs, not base Aeros
    |- SmallCraft
    |   |- Dropship
    |   |- EscapePods                     // This should probably go under Aero, but out of scope for this PR.
    |- Jumpship
         |- Warship
         |- SpaceStation   

in service of reducing the number of classes that needed updates for IBB. This should also allow reducing the code in Aero considerably and moving ASF-only functionality into that class, if desired.

2. Updated the Internal Bomb Bay quirk tooltip and text.
3. Added handling for Internal and External Bombs, including updates to configuration and bomb targeting dialogs.
4. Added IBB-related End Phase report, with relevant messages and explosion check / damage application.
5. Added ephemeral Cargo Bay generation for Aeros that mount the Cargo Bay miscellaneous equipment, as opposed to actual bays. These are not saved, but are used when calculating bomb space for IBB (and, perhaps later, for cargo?).
6. Fixed "Invalid Design" checks for A) extra weight on ASFs with internal bombs and ephemeral bays, and B) "BA ECM" on Small Craft (MekHQ Issue #1970
7. Added accounting for ground-fire-only damage per entity; this is required for 4) above.
8. Added separate listing of Internal and External munitions for summary view and MUL saving/loading.
9. Added ability for VTOLs to bomb their current hex if a "bomb" hex was not added during the Move phase - this appears to have caused some confusion, and VTOLs should be able to bomb their final location in the Attack phase.
10. Fixed a timeout error that would cause Princess to hang when attempting to move ground units in the presence of a large number of bombs. This may be the root of some of the recent Princess hangs we have not been able to track down; I will investigate further.

TO-DO / Not Yet Implemented

1. Separately accounting for each bomb in each disparate cargo bay: Cargo Bays need to be upgraded to a real Class with internal logic and accounting for this to be feasible. Currently we offer no way to account for location of bombs until they are instantiated after leaving the lobby; everything just gets thrown into "NOS". This unfortunately means that cheesing bombers with multiple 6-bomb bays won't protect IBB users.
2. Counting cargo space filled with bombs as "used": see 1).
3. Effect of a Cargo crit on aerospace units mounting internal bomb stores and using IBB: forum question here is currently being researched; currently no effect.
4. Verification of Fighter Squadron bombing capabilities; this came up as a question during development and is apparently not yet settled.

Testing

1. Ran MM tests in Idea
2. Tested configuration, saving, loading, and MUL reinforcement with all valid Internal Bomb Bay unit types.
3. Verified Princess operations with Internal, External, and mixed munition loads.

Note:

I updated the JVM options in build.gradle to use 4GB of RAM and disable AWT grabbing (source of a lot of freezing while debugging AWT windows). I can remove this if folks don't feel it's necessary for them.

Close #4397

[kuronekochomusuke]

can you update the Advanced Search Unit Type tab layout to reflect the new class structure in TWAdvancedSearchPanel?

the Conventional Fighter Fixed Wing Support should be on the same line as Aerospace Fight, since it now a child

the layout was meant to follow the class hierarchy

[kuronekochomusuke]

in MechSearchFilter this should be removed since there is a class now.

    if (mech.isAerospaceFighter()) {
        entityType = entityType | Entity.ETYPE_AEROSPACEFIGHTER;
    }

[NickAragua]

I'm not sure that your last merge went well, you went from 60 to 125 files

[Sleet01]

I'm not sure that your last merge went well, you went from 60 to 125 files

No, it definitely did not -_-;
Failures are due to a merge issue.

Increase in size is probably due to the rebase.

[SJuliez]

I'm seeing strange files in this, like the userdirhelp I wrote looking as if it was new, a new unit, gradle.build changes (intentional?). I'm not sure what to do about it. Can you look into this?

[Sleet01]

I'm seeing strange files in this, like the userdirhelp I wrote looking as if it was new, a new unit, gradle.build changes (intentional?). I'm not sure what to do about it. Can you look into this?

The gradle change I mentioned in the commit comment: it enables more stable debugging of AWT objects but can be pulled out if folks don't like it.

The other stuff is likely due to rebasing and merging a change I'd made here on GitHub in the web UI back to the PR branch. If work takes a long time I like to rebase to the latest master state often so there's less work to do when my PR gets pulled (if it gets pulled).
The "new" files, including that new ComStar unit, were all added to MegaMek after I created this PR; rebasing adds them to this branch's history but when the PR is pulled they will be discarded as unnecessary changes. But rebasing ensures that my updates won't break due to more recent updates to the base code repo.

[Sleet01]

I'm not sure that your last merge went well, you went from 60 to 125 files

Well, looking back, I think you're right - something is screwed up.
I'm going to try creating a new branch from the initial PR commit, rebase to latest master, and then apply the last few fixes.
If that works I'll close this PR and open a new one from that branch.
The MHQ PR can stay as-is; nothing there has been changed by this turmoil.

[Sleet01]

@NickAragua @Windchild292 @kuronekochomusuke @SJuliez @HammerGS

Apologies for the churn. I'm closing this PR in favor of a cleaner one, without all the extra files and broken merges:
#5003