OHara

You can, if you like, pitch your plane in the SPH as it would sit on the runway, and use 'absolute' mode, with the hexagon 'snap rotation' indicator on, to rotate the wheels  square to the runway. 
But maybe those details are already good.
The steering you describe sounds like the reaction wheels might be active, because the steering inputs to reaction wheels cause torque, which accelerates the rotation of the craft, and then when you release the input the momentum of the craft keeps it turning.   The same is true to some extent with the rudder and tailwheel steering.
Front-wheel (main wheels) steering is generally not done with tail-wheel aircraft, but if you used steerable wheels there the steering would be enabled by default.
Taildraggers really do tend to "ground loop" because your main contact points with the ground are in front of your centre of mass.  You need to keep pulling back on the stick as you brake, to get some weight on the tail so the tailwheel drags on the ground if you start to loop, and you cannot brake very strongly.

there is a note in the changelog for 1.11.0: * The LFB KR-1x2 Twin-Boar Liquid Fuel Engine now has the correct diameter.
which probably broke the flag.  So to restore the flag find the original twin-boar under Manufacturers : Kerbodyne

Looks like no-one recognised the problem, so good idea to put the craft file where we can see it.
There is a line in the craft file saying that one of the MK2 fuselages should be attached to a decoupler
    link = radialDecoupler1-2_4294554710
but there is no decoupler with that ID number.   Somehow the craft file has become internally inconsistent.
If I delete that one line, using a text editor, then the craft loads and seems to be working as intended.

Looks like no-one recognised the problem, so good idea to put the craft file where we can see it.
There is a line in the craft file saying that one of the MK2 fuselages should be attached to a decoupler
    link = radialDecoupler1-2_4294554710
but there is no decoupler with that ID number.   Somehow the craft file has become internally inconsistent.
If I delete that one line, using a text editor, then the craft loads and seems to be working as intended.

Looks like no-one recognised the problem, so good idea to put the craft file where we can see it.
There is a line in the craft file saying that one of the MK2 fuselages should be attached to a decoupler
    link = radialDecoupler1-2_4294554710
but there is no decoupler with that ID number.   Somehow the craft file has become internally inconsistent.
If I delete that one line, using a text editor, then the craft loads and seems to be working as intended.

The bug was reported for linux (link).  Squad sometimes fix bugs without even noticing them on the bug-tracker, but they have not yet acknowledged this one.
The bug-report says this old fix still solves the problem:
  I'm collecting such fixes here for folks who do not have a login to the bug tracker.

Having many craft and bases in your savefile only makes saving the game take a bit longer.  KSP only simulates physics for craft within about 2km of the craft you are piloting.
I have 'persistent.sfs' files around 5MB that cause me no problem.   I think size of the save-file is a reasonable measure of the number and complexity of the craft in flight.
If you keep the game running for a long time (hours) in one sitting, though, @Anth12 has noticed that KSP gradually uses more and more memory, and that problem is worse with a larger save-file (link to bug report).   At some point the operating system will slow everything down while trying to keep so much memory available to KSP.

Maybe the antenna in the satellite is not a 'relay' antenna.  
I don't know the rules for communications links, but there is a post here (link) that explains them and the types of antennas.
You can disable the communications rules temporarily with
  Pause (Esc on PC)  =>  Settings   =>  Enable CommNet :off

It is not possible under any circumstances. 
The Convert-o-tron Jr was designed for intermittent use only.  The only clue you see in-game is that 'max cooling' is less than 'cooling required'.
When this came up before (link, link) people uncovered the reasons it was made this way.  There is a patch (link) to change the rules if you want to.

People use "modulo arithmetic", @FruitGoose, to mean arithmetic where you only care about the remainder.   
After n orbits of a satellite, the planet beneath will have rotated m full times, plus a little bit more.  That little bit more would be the remainder of nT ÷ mD, if the orbital period is T and the rotational period is D.  If you want the satellite to eventually cover every 5° of surface you want the remainder to be 5°/360°.   But that leaves a tricky problem to pick the orbital period T when you have so many possibilities for n and m.  
I put a ScanSat image at right because that is the easiest way to draw the orbital tracks across the ground.  The idea is to put the ground tracks so that painting ± a survey distance from the ground track eventually covers the whole planet (which ScanSat happens to draw for us)  and to set up the orbit so that the 'eventually' is as soon as possible.  People solve this problem using the ScanSat mod by adjusting the orbit until the equator-crossing markers are spaced as they want.
What I was assuming in my earlier post with 1/N, 2/N, etc. , was that I had might as well divide the spacing between the first and final ground track evenly among all orbits.  Then the scanning pattern will repeat exactly after N orbits and the planet will have rotated exactly M times.  NT = MD 
After k orbits the planet has made kM/N rotations, which is some whole number plus a fraction (kM mod N ) / N.   If M and N are mutually prime (i.e. the fraction N/M cannot be reduced like 12/9 -> 4/3) then as k runs 1,2,3,etc., (kM mod N) visits all positive integers less than N.   So we pick 1/N ≤ x/360° to space the eventual set of ground tracks by x degrees longitude, or closer.
The pattern finishes in M rotations of the planet, so we want the smallest possible M.  Atmosphere or mountains puts a lower limit on the orbital radius a = (T² GM / (2π)²)^(1/3), so atmosphere also puts a lower limit on the orbital period T.   Since T = (M/N) D there is a lower limit on M.     For Kerbin, for example,  M ≥ 0.086×N to stay out of the atmosphere.
So then to cover Kerbin completely with a scan that covers ±5° we need orbits spaced by 10° : 
N ≥ 360°/10° = 36
M ≥ 0.086× N =3, but 3/36=1/12 and 4/36=1/9, so 5/36 rotations is the first orbital period that will cover without overlapping ground tracks, taking 5 days to complete.
But sometimes slightly tighter spacing, slightly bigger N, allows a lower orbit for a net win:
N = 37 spaces ground paths a bit closer than 10°
M ≥ 0.086× N =4, and that is mutually prime to 37, so an orbit with period 4/37 rotations (2330 s) gets the job done in 4 days.
Those orbits cover the whole planet on just the north-going orbits, or while the planet is in daylight, which might be what you want. 
If you can scan on the dark side of the planet as well, then in addition to the (kM mod N) north-going passes over the equator there are south going passes at (kM + (M+N)/2 mod N).  These extra passes interleave helpfully if (M+N)/2 mod N is an integer, so the equator is covered in half the orbits it would take to finish the planet.  The smallest M where M and N follow all these rules is (N = 39;  M = 5) and an orbital period 5/39 rotations will completely cover Kerbin's equator in about 2.5 days, leaving only small uncovered slivers to be completed in the remaining 2.5 days.

Maybe your relay was in just the correct spot, when you hit Jool's atmosphere.  The original request for the plasma effect mentioned how the US Space Shuttle worked around it with the  Tracking and Data Relay Satellite System. There are parameters like 'commNetDotForBlackoutMin' in Physics.cfg with comments that indicate the plasma effect fades away for communications directed between 30° and 60° of retrograde, and has no effect at all if the link is within 30° of retrograde to the craft.
 

It is not just you.  My fairings also sometimes destroy my solar panels,  when I build the fairing  close to the payload. 
(I never considered it a bug, since the now-free fairing pieces really could hit other parts.)
I started leaving more room inside the fairing.  Other people use the 'confetti' style of deployment.  I'll try the time-warp suggestion.

Somebody saw a similar symptom here https://forum.kerbalspaceprogram.com/index.php?/topic/181384-* and https://bugs.kerbalspaceprogram.com/issues/20934
That time it was because of sentinel probes, but maybe their workaround will work for you: letting KSP run at 1× speed (no time-warp) gradually reduced the number.
(Or, if you are good with programmable text-editor, you can remove all the VESSEL blocks for spaceObjects from your *.sfs file)
Year 187 is a large 'UT' measured in seconds, so I can imagine you found a bug with the expiration clock the KSP puts on these undiscovered asteroids. 
[Edit:  I noticed your flight has lasted 187 years, so I suppose your calendar time could very well be year 233, which is 231 seconds, which would be the largest number of seconds in the common-size integer in a computer, which opens the door to programming bugs.]

I understand you to mean 'KSPInstallerx64-1.11.0.exe' (or some similar name) when you say 'the installer'. 
You need to run (execute) that file in order to unpack all the files for KSP.   That installer program will then let you choose the directory where you want the new KSP to be installed. 
Many of us here choose a new directory when a new version is available.  Then we copy the old settings.cfg and copy our saved games into the new directory.  Sometimes the rules change or bugs appear, and we want to be able to go back to the old version of KSP.
The upgrade patches are a different way to get the new version.  You do not need to use the upgrade patch if you downloaded the Installer.  (Those of us on slow internet connections can save time by downloading relatively small patch, and then letting it change what it needs in the KSP installation we already have.)

The EAS-1 seats count for contracts in my game.  The rules might have changed when KSP started allowing us to fill the seats in the VAB.
The way to check is  to put the proposed facility on the launchpad, select the contracts button on the right side of the screen, and look for what conditions get a green tick mark.

There is a recent description of something very similar on the bug tracker (link) but not a real bug report.  I'll mention the very good report in the OP on that bug-tracker item.
Version 1.7.3 does not show the problem, but I agree that version 1.10.1 obviously does. 
Someone else noticed it and revived a very old thread (link).   The module-manager patch in that thread ( @PART[*]:HAS[@INTERNAL[*]] {!INTERNAL,* {}} ) solves the low frame-rate for me but of course also removes all views of the inside of the craft (all IVA views).
Another workaround is, each time after returning from map view, to EVA a Kerbal and reboard him, or switch to some other craft-or-kerbal in the same physics bubble, then back to the problematic craft.
I notice that memory use goes quickly to 98%, which makes me suspect the method of IVA rendering is over-using garbage-collected memory.

I think no.  
It has been suggested to Squad on the bug-tracker (here) where often players post their workarounds, but it seems that no-one has found a way.
(Well, I suppose you could go into the file Squad/Experience/traits.cfg and change the EVAChuteSkill to level-6 and restart the game, so they never have chutes until you restore traits.cfg, but that would be overkill.)

It is not just you, @Kerbalwerks This is a new bug since version 1.9.0 and it is on the bug-tracker (link)

There is a group of bugs about the service modules. What you describe seems closest to this one (link). The way the service module marks as stowed parts outside of it is a separate bug (that I remember seeing but cannot find right now).
The Making History mod is noticeably buggier than the rest of KSP, so be warned, but you might like it anyway.
You already noticed that you can work around the problem, by leaving the shroud on in the VAB and deploying it in flight.
If you want to change the rules in your copy of the game game, so that parachutes don't check if they are stowed,
you can edit the configuration files, or use a ModuleManager patch like
@PART[*]:HAS[@MODULE[ModuleParachute]] {
  @MODULE[ModuleParachute] {
  %shieldedCanDeploy = true
}}

I don't think it is normal for solar panels to be destroyable by air forces when retracted. 
At least, I've never managed to destroy any, even when doing low-altitude gravity turns.

You list of principles makes sense to me.  
If this wording makes a difference to you, fins and wing-like parts keep the rocket straight mostly by lift in the back, rather than just drag.  That is, they give a force to the side when they are turned relative to the rocket's direction of motion.  That side force has a nice long lever arm to straighten the rocket. 
And fins don't have much drag in the sense of holding the rocket back, when they are aligned to the airflow --- as they are when they succeed keeping the rocket going straight.
Another approach, when you have a pilot or probe core that can hold prograde  , is to let SAS hold prograde at the stage when you currently turn SAS off.  Steerable fins are helpful for this because their forces go up and down with the relative strength of aerodynamic forces.  But, SAS seems a more brute-force approach, and I would say that "more fins" is the more elegant solution.
The blue ball in the VAB shows center of lift; that is, where the wing-like parts will apply a side-force if the rocket tips relative to is motion through the air.  Great for airplanes, where that is the bulk of the force that turns the craft, but not the full story for rocket stability.  Drag forces are not counted in placing that blue ball, but drag does tend to flip the rocket.
The side mounted parts, and the exposed flat portions when different-sized parts meet along the main stack, get more drag in KSP than one would expect.  (I started a thread (link) collecting facts players have noticed about drag.) KSP treats these as if exposed to the full airflow, ignoring any protection from being tucked into the sides of the rocket.  That is why the fairing in your images was needed. 
.. and welcome to the forum. 
Your image links worked fine; many users take the URL that resolves to the image file, like "https://www.dropbox.com/s/k15dmv4ysbaruzq/screenshot8.png" ending in .png, and give that to the "insert image from URL" button, so that the image appears directly in the post.

and I downloaded it and see the same problem as you do.  There is an option in the alt-F12 menu under Physics: Aero: 'display aero data in menus' that lets us check if parts have zero drag, while still rolling on the runway.
If I move the Mk3 drone core forward to go between the Mk3 service module (from the mod) and the stock long Mk3 cargo bay, then the contents of the long cargo bay are properly shielded and show zero drag. 
KSP seems to think that the Mk3 service module from the MK3 Expansion mod is open.  When cargo bays are in a connected chain it requires that all of them are closed before it removes drag from the contents of any of the bays. (I don't know why they made this rule, but can guess the programmer had some good intentions, but in hindsight it seems overly complicated.)
The Mk3 service module from the mod never shields its contents, so it looks like KSP thinks it is always open.  I notice that the configuration file for that part has two entries of ModuleCargoBay, which seems strange.  (I'm not familiar with that mod myself, so won't point it out to the mod author unless and until I look into it a bit more.)

When you are controlling a craft with action-group sets, you should see a new button in flight-mode, above the delta-V button, that lets you switch sets.
The keyboard commands (in default Windows keybindings) are F6 and F7 to switch forward and back through the sets.

You understand correctly.  SAS does not control the axis groups.
(Players have made a suggestion to change this https://bugs.kerbalspaceprogram.com/issues/22946)

KSP has a rule preventing us from deploying parachutes through a closed fairing.   Usually, the hole at the bottom of your fairing after the rest of the rocket has detached would make it no longer 'closed' but a recent bug (https://bugs.kerbalspaceprogram.com/issues/21915) makes KSP fail to notice that kind of opening.
If that bug is the cause of your problem, you can try the workarounds:
+ Quicksave / Quickload, then deploy the parachute, or
+ Deploy the fairing explicitly before the parachute, or
+ Choose another part, beneath the decoupler that opens the hole, as the 'root part' of the rocket.
(None of these workarounds looks really convenient for your rocket.)
If you want to change that rule in your game, and generally be able to deploy parachutes through fairings,
you can edit the configuration files, or use a ModuleManager patch, something like
@PART[*]:HAS[@MODULE[ModuleParachute]] {
  @MODULE[ModuleParachute] {
  %shieldedCanDeploy = true
}}