Snark

Unfortunately, that's the sort of thing that's practically impossible for someone to just look at and answer the question.  Could be just about anything.
The usual answer is tedious but probably unavoidable:  figure out which one it is, by process of elimination.  That is, try running with only half the mods installed.  Did it get better, or stay the same?  That tells you which half of the mods the culprit is in.  Then take that half-of-the-mods, and install half of that, and keep repeating until you've whittled it down to just one.  Then you can go post in that mod's thread to ask about the problem.
The other possibility is that it's not one mod that's the culprit, but an overall system-performance thing, which presumably be indicated by "it gets faster when I'm running a lot fewer mods, regardless of which mods they are."
About the only other thing I could suggest would be to maybe crack open the KSP log file and see whether it's getting spammed with gazillions of error messages.  It won't necessarily be so... but it could be.  (Suddenly crappy frame rate in certain situations can sometimes be a symptom of "something's throwing lots of exceptions".  Exceptions get logged, and the stack trace in the exception may point the finger at what code is doing it.)

^ This, if you want to do the math by hand (or in your own spreadsheet), and don't want to have a mod (such as BetterBurnTime) do it for you. 
Actually, Spricigo had it right.    (This is essentially the same math that BetterBurnTime does.)  This is  exactly how one compensates for the fact that the acceleration gets faster as the ship gets lighter.  Example:
I need to do a burn with 1000 m/s of dV I do the math (using the rocket equation and plugging in my Isp) and figure out that I need, say, 10 tons of fuel to do this My engine consumes 0.1 tons of fuel per second Therefore the burn will take 100 seconds. It works because even though the acceleration won't be constant, the fuel consumption rate will be.
 
If all of the engines have the same Isp as each other, then the Isp of all of them will be the same as the Isp of one of them.  (For example, the Isp of a Terrier is 345 seconds.  If you have a ship powered by four Terriers, its Isp is still 345 seconds.)
If you have multiple engines simultaneously firing, and they have different Isp values from each other, you combine them thus:
Ispcombined = Σ Fn /  Σ (Fn / Ispn)
 
...where Fn is the thrust amount of the Nth engine, and Ispn is its Isp.
In other words, add up all the thrusts of all the engines.  Then divide that by another sum, which is generated by adding up "thrust divided by Isp" for each engine.
Example:  You have a Skipper (650 kN thrust, Isp 320 sec) and two Terriers (each 60 kN thrust, Isp 345 sec).
Add up the thrusts, 650 + 60 + 60 = 770 kN. Add up the thrust-per-Isp numbers.  (650/320) + (60/345) + (60/345) = 2.379 kN/sec Divide the former by the latter.  770 kN / 2.379 kN/sec = 323.655 sec Thus, the Isp of the combination would be 323.655 sec.  Note that it's a whole lot closer to the Isp of the Skipper than it is to that of the Terriers.  That's because the Skipper has enormously more thrust, so it consumes the large majority of the fuel.  Since most of the fuel is being funneled through the Skipper, the Skipper's Isp predominates.
 

Plasma blackout isn't relevant here, since all your satellites are orbiting outside the atmosphere.  What the plasma blackout option does is to cut your communications when you're going through the hot part of reentry.
^ That's it.  That's your problem right there.  You've reduced your antenna ranges to only 65% of their nominal values.  Therefore, your network is operating at the extreme outer limit of their (reduced) range.  Change that to 1.0 and you'll be good to go.
When you install OPM, it tinkers with the ranges.  It boosts the power of the level-3 tracking station by 8x, and boosts the power of all antennas 4x, so that it's possible to reach the outermost planets.  So that's independent of your choice about antenna ranges.
Personally, I really don't care for that solution.  OPM adds new planets to the outer edges of the solar system, but it leaves the inner system intact.  Therefore, boosting like this will allow talking to Sarnus, Urlum, Neidon, and Plock... but it makes everything way overpowered for the inner solar system, in my opinion.
So, for playing with OPM (or other mods that feature enlarged solar system, such as New Horizons or Galileo's Planet Pack), my preferred solution is to have an upper-tier antenna up at the top of the tech tree that can reach much further than the RA-100, and leave all the other antennas and tracking station power alone.
Fortunately, there's a mod for that, if you're so inclined. 
Does basically what it says, adds a new part which is a 1000G antenna.  One of the things this mod also does is, if it's installed alongside OPM, it undoes the power boost that OPM does by default, so that everything behaves like it does in the stock game.

Hello, and welcome to the forums! 
Alas, no.
Only relay antennas can make relay connections.  Direct antennas can make only direct connections.
When you're flying the polar satellite, it can connect directly to Kerbin, using the 88-88, because that's a direct connection.
When you're flyng the equatorial satellite... no go.
It can talk directly to Kerbin via the DTS-M1... when Duna's close to Kerbin.  At DSN level 2, the comm range to a DTS-M1 will be 10G, which is enough to talk to Duna when it's near, but not when it's far. If it tries to use the polar satellite as a relay... the 88-88 is irrelevant and might as well not exist, since it's a direct antenna and therefore can't participate in a relay connection.  So in this case, all that matters for relay purposes is the RA-2. That RA-2 has the same power as the DTS-M1, and therefore the same range for talking to a level-2 DSN:  namely, 10G, i.e. enough to talk to Duna when it's close, not when it's far. So, with the setup you've described, basically either Duna is close (within 10G) or far (above 10G).  When it's close, your equatorial satellite can talk to Duna either directly via its DTS-M1, or via the relay.  When it's far, it can't talk either way, and is a doorstop.
 
 

It's almost certainly this.  Easy to check:  just look at the AN/DN markers with respect to the target orbit.  Do they say 0 degrees, or 180?  If they say 180, you've got it backwards.  Switch to the other direction and you're all set.

First... why all the multiple antennas?  The RA-15 has a power so much insanely higher than the HG-5 that adding the HG-5 doesn't really do anything.  And given that you have the RA-15, why do you need the Communotron-16 S at all?  Seems to me that the RA-15 is the only antenna you need.
Anyway, on to your problem.  You're way over-killing the dV requirements, and ions aren't really needed to go to Duna.  With a good transfer window, you only need ~1050 m/s (plus a small maneuvering reserve) to go from LKO to Duna orbit, if you're aerobraking on arrival.   You need only ~1700ish m/s to do it even if you're not doing any aerobraking.
So, how much ship do you need to do that?
Let's say you put together a craft consisting of the RA-15 (0.3t), plus a HECS2 (0.2t), plus a 0.5-ton LFO tank (0.5625t), plus a Spark engine (0.1t), plus a couple of the folding solar panels (0.025t each).  You're looking at a total satellite mass, with full tank, of 1.21t, of which 0.5t is fuel.
Given the Spark's vacuum Isp of 320, that gives you a dV of just under 1700 m/s... which coincidentally is about what you need to go from LKO to low Duna orbit without aerobraking.  Toss in some aerobraking, and that's enough to get you to your destination right there.  You could move up to a 1-ton fuel tank instead of 0.5-ton, to give yourself some extra breathing room:  that would boost your dV up to 2600 m/s, which would give you a big safety margin, allow for suboptimal transfer window, and still keep the total ship mass to under 2 tons.
Side note... it's physically impossible to get 1G acceleration with ion engines, even with an infinite number of them.  The engine itself masses 0.25t, which sets an absolute upper limit of just over 0.8g even if it didn't have to deal with any mass for fuel tanks, probe core, solar panels, or anything else.

Basically, no.
Bear in mind that the cubic octagonal strut (and other parts of its ilk) aren't "dragless".  They're physicsless.  There's a difference.
Once upon a time, in the early days of KSP, the so-called physicsless parts really did have zero mass and zero drag.  You could spam them and it would make not one whit of difference to the vessel's performance.
Those days, however, are long gone.  Now, they do have mass and drag.  However, it works differently from "regular" parts.  The way it works is, all the mass and drag for the "physicsless" part get added to the part's parent-- or, if the parent is itself physicsless, to the closest "ancestor" part that's not physicsless.
So, imagine that you have a part with a flat upper surface that's, say, 0.625m across, and you're thinking about putting the small nosecone on it, or alternatively, some physicsless part such as the cubic octagonal strut.
Here's how the game would see those two options:
The nose-cone option:  Nice and low-drag.  The flat upper surface of the parent part won't hurt you, because it's not exposed (the nosecone sits on top of it).  The nosecone is nice and pointy.  Everybody wins. The physicsless-part option:  Draggy.  The game sees the physicsless part, so adds its mass and drag to the part you've attached it to.  The part you've attached it to therefore still has that flat forward-facing surface (because the physicsless part doesn't count for occlusion purposes), and then you add some extra mass and drag because of the presence of the physicsless part. In other words:  Physicsless parts can never help you, in terms of drag.  All they ever do is add drag.  So no, your suggestion's not going to gain you anything in terms of drag-- quite the opposite.

It's a little different from launching a ship to collect a kerbal in Kerbin orbit... but not that different.
Launch into circular LKO, in the correct plane (not equatorial), well in advance. When the asteroid crosses Kerbin's SoI, it'll be at some oddball plane, generally not equatorial. So, launch directly into that plane, not equatorial.  Reason #1:  it'll save you scads of dV.  Reason #2: it'll make setting up the intercept much more straightforward. To do this, just wait until Kerbin has rotated to the point that KSC is located directly underneath the future track of the asteroid, and then launch in the appropriate direction. Once you're in LKO, you'll probably be a degree or two off the exact plane, unless you're really good.  So do a small burn at the AN or DN to get this nicely lined up, so you're perfectly in the plane that the asteroid's going to be. Do a burn to raise your Ap up to the asteroid's projected Pe. Drop a maneuver node at the point of your circular orbit that is exactly 180 degrees opposite where the asteroid's projected Pe is. Drag prograde on the node until it raises your Ap up to where it just "kisses" the asteroid's path, and then just a tiny smidgeon beyond (so the single intercept marker splits into two markers, but they're still really close together). Leave your ship parked there until the asteroid arrives at Kerbin's SoI. Set up the rendezvous. This is now simple and low-dV to do, because of the setup you've already done. Just drop a maneuver node right at your Ap (which is the asteroid's Pe).  Note that there will be a marker showing the asteroid's projected position at your next intercept after the maneuver node. Click the "+" button on the maneuver node-- note that the asteroid's projected position gets closer.  Do that a few more times until the asteroid's projected position gets fairly close.  If it goes past your projected intercept, you clicked "+" one time too many-- in that case, click "-" to back up, then stop. Now drag the prograde handle on your maneuver node, and watch your projected orbit start to get bigger.  As it does this, the projected intercept point will slide closer and closer, and your distance-at-closest-approach will become smaller and smaller.  Carefully adjust until you've gotten that intercept distance down to zero, or close to it. Do the burn when it's time. Wait for the asteroid to come to you. Match velocities at closest approach. Profit!

Moving to Gameplay Questions.
Is that an African kerbal or a European kerbal?
Here's a recent discussion on the topic:

Looks like the answer is a bit over 600 m/s.

A few things.
First, as folks have said, you want to have CoL behind CoM:
 
...However, it's important to note that simply having CoL behind CoM does not necessarily mean you're aerodynamically stable.  Lots of people in KSP think that, but it's not the case.   It's possible to have CoL behind CoM and still be really unstable.  People get bitten by that all the time-- especially folks who try to build a KSP replica of the US space shuttle.  (Just do a forum search for "unstable shuttle" and you'll find lots of discussions about the problem.)  The reason for this is that a craft that has its CoM towards the back is likely to be unstable, regardless of where its CoL is.
So, some ways to improve your stability:
Move your CoM farther forward. Make sure that you've turned off control authority on your vertical stabilizer for everything except yaw.  If you haven't, then it's not helping you as much as it can, because it ends up fighting itself (its efforts to add yaw stability directly counteract its efforts to add roll stability). Turn off the canards' control authority for everything except pitch.  Any time the canards deviate from 0 degrees, they're adding drag to the front of the plane, which tends to make it want to flip.  But the only time that their deviation actually helps your stability is for pitch control.  So you want to make sure that the only time they deviate from 0 degrees is when they're actively trying to help your pitch. As others have suggested, add a horizontal stabilizer at the back of the plane, as far behind the CoM as you can make it. Be aware that those ailerons that you have on the wings are doing essentially zero work to help your stability.  They may help you for roll authority, but they don't add anything to pitch stability at all.  That's because they're right smack dab on your CoM, so they have no lever arm to work with.  Control surfaces only work to help your pitch if they're far in front of or far behind your CoM (and "behind" is better than "in front of", which is why you need a stabilizer at the back).  

Irrelevant.  Or, at least, marginally relevant.
Not super important.
It's a pretty common myth in KSP that "CoL behind CoM = stable."  Yes, you want your center of lift to be behind your center of mass... but that's not even vaguely the most important thing.
This screenshot pretty much says it all.  Look at where your CoM is!  It's way the heck at the back of the craft.  In a situation like that, it doesn't matter where your CoL is... a CoM at the back of the craft, with that huge lightweight draggy fuselage sticking out in front, is going to want to fly backwards.
The center of mass of the craft wants to be in the front of the craft.  That's how we all build rockets for ascent, after all-- try to keep the CoM high, towards the front.  The same principle applies during descent.
It also doesn't help that you have basically no control authority on the craft.  All your control surfaces are located at the back of the ship, right next to the CoM, which means they have practically no lever arm to work with and therefore might as well not even be there.
Basically, what you're trying to land there is a badminton birdie that's pointing feathered-end forward.
This happens all the time with people who want to build space shuttle replicas in KSP.  It's kind of unfortunate:  the game makes it really really easy to build something that looks just like the space shuttle, because Squad has gone out of their way to make parts (the Mk3 cockpit, the Big-S tailfin, the Big-S delta wings, the shape of Mk3 fuselage parts, the Vector engine) that are designed to look just like the shuttle... except that it won't fly like the shuttle.  Because if you build something in KSP that looks just like the real life shuttle, the CoM of your replica will be nothing at all like the real-life shuttle.
There are lots of ways to make your craft stable on landing, but they're going to involve doing things that make it look less like the US space shuttle, so if you're counting on the aesthetics of looking like that, you're going to be disappointed.  On the other hand, if you're just interested in building something that works and don't care whether it looks like the shuttle, then you have options. 
So, there are two things you can do:
Move the CoM far forward.  Way far forward.  As far as you can manage it. This can be tricky, given that your main ballast (fuel) is all gone, and your heaviest components by far (the engines) are all clustered at the back of the ship. One design that can work well is to go with more of a Skylon-like design:  put your engines close to the middle of the ship, mounted on the sides, rather than having them way back in the back of the ship. There are other things you can do, too (KSP's great at giving design options!) ... but given how heavy the engines are, moving them forwards is probably the easiest thing to do. Make sure you have control surfaces that are far away from the CoM. Ideally, this would mean move your CoM way far forward, and keep your control surfaces at the back.  The fact that you've moved the CoM forward will give your surfaces the lever arm they crave. However, if you're having trouble moving the CoM forward... put some canards way out on the front, as far forward as possible.  They'll help maintain control if you can stick closely to prograde (i.e. you have SAS to help with that).  A CoM-at-the-back ship is still going to be aerodynamically unstable, which means if you ever waver even slightly off prograde, it's going to flip backwards and stay that way.  But if you can manage to ride the knife-edge of stability, poised precisely at prograde, then this can work.  It's just a bit of a nail-biter, is all. Make sure you've turned off everything except yaw authority on your tail fin. The only reason to have that big ol' vertical stabilizer is to give you yaw stability.  It shouldn't try to compensate for anything other than yaw. However, by default it'll try to help you with roll, too... and the result is a complex interaction that causes it to fight itself (trying to yaw induces roll that it tries to compensate for by rolling the other way which requires deflecting in the opposite direction and cancelling out the yaw...).  Long story short:  you'll find better yaw stability if you turn off everything else on your vertical stabilizer.  You'll also be more stable if you can move your tail fin down some (i.e. in the ventral direction); right now it's sticking up so high that it induces a lot of roll whenever it operates.  Use the offset tool to move the fin a bit closer in to the central axis of the ship.

+1 to both of the previous posters.  A few more comments:
It doesn't matter where you put reaction wheels on the ship, in terms of how effective they are.  They have equal effect no matter where they're located.  (It can matter in terms of wobble, if you have a very wobbly ship and the reaction wheels are the cause of the wobble.  I'd say that's not the case here; your wobble is due to other factors.) Engine gimbal on a high-thrust ship, especially a very tall one, is so much stronger than reaction wheels that the reaction wheels have negligible effect, at least during the high-thrust portion of ascent..  You're not going to stabilize that way. ^ This.  Untweaked engine gimbal tends to be way overpowered for very tall ships, since they have a big lever arm to work with.  I almost always end up reducing the gimbal range on Mammoth / Rhino / Mainsail / Skipper to around 30%.  Might be worth a try.
(Though admittedly, the SAS tuning in 1.2 is so much better now that this might not be so much of an issue anymore.  I haven't tested it specifically, but I have noticed that "hold prograde" during ascent with a gimbaled engine doesn't wildly spam the gimbal the way it used to.)
^ This.  This right here.  I'd guess that this is overwhelmingly the biggest contributor to your problem.
KSP ships are a "tree" structure, which means you can't have closed loops of parts (except for struts and fuel lines).  It's not possible to mount four engines like you've shown and have them all connect at the bottom; only one will connect.  So basically, you have the entire upper part of your rocket (the whole part above the LV-N's) mounted on a single LV-N which is on a stack separator.
 
If you're not averse to using mods, then I highly recommend SpaceY, once it (along with ModuleManager) becomes available for 1.2:
Nice things about it for your use case:
Mostly what it's about is adding big parts (ginormous 5m parts are a thing).  So if you're building a really big rocket, you can make it with a smaller number of really big parts, which makes the ship a lot stiffer. It also adds some really cool multi-node interstage adapters that will allow you to actually do what you're trying to do (i.e. have multiple LV-N's in-line with your bigger-diameter stack), while maintaining a stiff connection.  These are really cool parts, would love to see something like them in stock. Discussion of what they are and how they work here.

^  This.  This is your answer, right here.
^ No.  This is irrelevant, for a couple of reasons:
"Enable crossfeed" only applies to resource-draining parts that use up stuff during normal operations.  It does not apply to the player manually transferring a resource between two containers.  For example, you can always manually transfer fuel between two fuel tanks, regardless of where they are relative to each other on the vessel, and regardless of what your crossfeed settings are. Crossfeed never applies to electricity, anyway.  As long as you have an enabled battery that has charge in it, its electricity is always available to all electricity-consuming parts anywhere in the vessel, regardless of crossfeed settings. The problem here is simply that @jebodiah1976 is in career mode and hasn't upgraded the science facility yet, as FullMetalMachinist points out.
 

Okay, got to my KSP computer.  I'm seriously puzzled by the difficulty you're having.  Works just fine for me.
Here's my sequence of operations:
Start a new ship in the VAB. Place a big orange tank. Pick a docking port off the parts tab. Hit "A" a couple of times to flip it upside-down. Hold down the ALT key. Move the mouse until the upside-down docking port snaps to the bottom node on the fuel tank. Click the left mouse button, placing the port. Release the ALT key. Below are some screenshots of the operation, depicting steps 3, 4, 6, and 7 from the above.




 
That's it.  Works exactly as I'd expect.  So, @qoonpooka, you're saying it doesn't work that way for you?

Welcome to the forums! 
It's because you're on Eve.  Specifically:  the Puff gets no thrust at high pressures such as are found there.  Details below:
Engines generally get less thrust when operating in atmosphere than in a vacuum (their Isp goes down).  The higher the ambient pressure, the greater the Isp loss.  Just how much it goes down depends on the engine-- they each have a different curve.
This makes a big difference on Eve, which has a very high surface pressure (5 times Kerbin sea level pressure).
If you want to see what the engine does, crack open its .cfg file and take a look at the "atmosphere curve".  Here is the config for the Puff engine:
http://wiki.kerbalspaceprogram.com/wiki/Parts/Engine/OMSEngine/omsEngine.cfg
This is the relevant part of the config:
atmosphereCurve { key = 0 250 key = 1 120 key = 4 0.001 } How to read this:  "At 0 atmospheres (i.e. vacuum), the Isp is 250.  At 1 atmosphere, the Isp is 120.  At 4 atmospheres, the Isp is 0.001."
Moral of the story:  you really don't want to try to use a Puff anywhere that has higher-than-Kerbin atmospheric pressure. 
 

Nope.
Not now, not ever, nor is it possible to add that with a mod.  You've bumped up against a fundamental limitation of the game.  Not just for panels, but for any part at all.
KSP models vessels as a "tree" structure:  there's exactly one "root" part (the first one you place in the editor), and pieces that you attach to it are its "children", and pieces you attach to them are their children, and so forth.  And a fundamental assumption built into the entire system is that a part can have only one "parent" connection.  This makes it fundamentally impossible to have a closed "loop" of parts.  It means you can't have multiple edge connectors on parts.  It means you can't join parts together in a circular ring, such as a space station torus.  The assumption is baked into the game at such a fundamental level that you'd have to completely eviscerate the game to try to change that-- basically, it's in the ain't-gonna-happen category.  And because it's such a fundamental part of the game, mods can't really do anything about it, either.
There does exist a special category of "compound" part that can bridge the gap by connecting at two endpoints; in the stock game, these are the struts and the fuel ducts.  Those are basically your only option in stock.
This means that to make really big wings, you need to use really big parts; there's not really any other option.  You've already mentioned using Procedural Wings-- that's probably your best bet.

Almost certainly caused by a mod.
It may be that you have an outdated mod, which worked in 1.1.2 but became obsolete in 1.1.3.
First suggestion:  Try uninstalling all of your mods (or, at least, the ones you installed before 1.1.3) and re-install with fresh versions that are compatible with the current version of KSP.
...Well, certainly you can, it will just be inconvenient for you.
Really, that's the only way to be sure.  You can try the reinstall-everything-at-once approach, and that may help you, but if it doesn't, you basically have to just use process-of-elimination to figure out which one is causing your problem.  Yes, it will be tedious and inconvenient.  But if you choose to run so many mods, you have to expect that sort of problem, and the inconvenience that comes with it.
Note that you don't necessarily need to test one by one.  For example, say you have 80 mods running.  Divide them into two groups of 40.  Try running with just one group installed, then the other.  If the problem only happens with one of the two groups, you've just narrowed it down from 80 to 40 at one whack.  Then you can take that group and further divide it in half, and keep repeating the process until you narrow it down to one.  In that way, you can narrow it down with a lot fewer than 80 repetitions.
Yes, it will be tedious even so.  If that sort of thing is more tedium than you can tolerate, basically your only option is to run fewer mods.

Moving to Technical Support.

Moving to Gameplay Questions.
Almost certainly the problem has nothing to do with when your Rapiers kick in.  Having them on doesn't stabilize the plane, they just make it go faster.
The problem is with your ship design:  specifically, it's not aerodynamically stable on reentry.  One very common problem with spaceplane-style craft on reentry is that their CoM may shift a lot during ascent as they burn off fuel.  Very often it will shift to the rear (depending on the ship design), making the plane very unstable, and you don't discover that until you come back into atmosphere.
It's impossible to say just how to fix it without seeing a screenshot of your plane.  If you could post one, we can offer constructive suggestions.
 

Here's the forum you want, @Mr. Quark.   Of particular interest is the "Plugin Development Help and Support" sub-forum.  It has lots of helpful stickied posts with various types of help.
http://forum.kerbalspaceprogram.com/index.php?/forum/36-add-on-development/
Broadly speaking, there are two things you can do:  change/add config, or add code.  A given mod might be only-config, only-code, or some mix of the two.
Tinkering with config requires a text editor and a familiarity with KSP config syntax.  It allows altering the parameters of the existing parts in the game.  If you can use some external tools such as Blender and Unity to add models as well, this lets you add new parts to the game.
Tinkering with code allows you to write new computer code to make the game do new and/or different things-- it gets at the behavior of the game itself.  (Mods that have code in them, like this, are referred to as "plug-ins".)  To make this sort of mod, you'll need Visual Studio (it's free) and a knowledge of C# programming.
The forum I link to above has all sorts of information about this kind of stuff. For further modding questions, that's the place to ask.

It's nothing to do with mods, it's a bug in the stock game and Squad knows about it.
It's affected by game speed (rate of updates).  The problem gets worse when things slow down.  For example, I didn't notice the problem at all the entire time I was playing 1.1.3 ... until I went to fly my big 450-part Jool mission, and the game slowed down, and now I can't get helmet lights to work at all when they're within range of that big ship.
Basically we just need to wait until the next patch so that Squad can fix it.

I would say to the OP that yes, your logic is sound.
However, in the case of "I want to go to Kerbin from Gilly", there's a third option you haven't considered:  Wait until Gilly is at its Ap around Eve, do a burn to escape retrograde from Gilly to drop your Pe down to very low Eve orbit (same as if you were going to Eve rather than Kerbin) ... and then do your main Kerbin ejection burn when you're at your Eve Pe.  This will give you a huge Oberth boost and save a lot of dV.
Of course, it'll make navigation, launch window planning, etc. more of a pain, so it'll likely be pretty inconvenient.  If you're not fortunate in terms of how the planets are lining up, you may need to do it in stages that are widely separated in time (e.g. do the Gilly-escape burn to get in a very elliptical Eve orbit; then wait weeks or months until your Eve Pe is pointing in the solar-prograde direction to do your Eve-escape burn; then maybe need to wait a few years doing multiple solar orbits until you get Kerbin to line up with your ship when you're at Ap).
But in terms of "how can I get from Gilly to Kerbin with the absolute minimum possible dV", that'll be your best bet.

Moving to Gameplay Questions.
If you'd like to take the math-and-old-fashioned-eyeball route:
Kerbin rotates once every six hours, i.e. 60 degrees per hour.  A ship orbiting in LKO takes roughly half an hour to go around once, so Kerbin will rotate roughly 30 degrees per orbit.
So when you're setting up your orbit, do it so that your orbital track passes east of the target, by roughly 30 degrees of longitude times the fraction-of-an-orbit to get to that spot.
You're unlikely to nail it perfectly, of course, so you'll need to do some corrections along the way, but that'll get you in the ballpark.  As for making those corrections, there are two places that are good to do it.
The first good opportunity is when you're 90 degrees, i.e. a quarter-orbit, before you get to the destination.  (That's because this is the point at which you get the most bang for your buck, i.e. the greatest amount of sideways adjustment to your orbital path over the target for a given amount of dV expended.)  So when you're about 90 degrees out, do a normal/antinormal burn to put your path-over-the-target at around 8 degrees of longitude (or slightly less) east of the target.
The last good opportunity is when you're getting pretty close to the target, so you can think in more Cartesian fashion without worrying about Coriolis effects too much, and just pretend you're not in a rotating reference frame.  When you're getting relatively close to the target, put your navball into surface mode, do a roll until the horizon looks level (sky above, ground below) on the navball), then compare your prograde/retrograde velocity markers to the target marker on the navball.  If it looks like you're pointing right of the target, do an orbit-normal burn to adjust.  If it looks like you're pointing left of the target, do an orbit-antinormal burn.  Once you've got it lined up so that the target marker is directly below (nadirwards) your orbit-prograde marker (again, while the navball is in surface mode), you've got it lined up perfectly and all you have to do is wait until the target marker hits the nadir on the navball.

That is correct.  The phenomenon is referred to as "cosine loss" (try searching for that phrase on the forums, you'll find a lot of talk about it). An engine that's thrusting perfectly prograde contributes 100% of its thrust in the prograde direction (since the cosine of zero is 1).  If the engine is pointed any other direction than prograde, then the component of its thrust in the prograde direction is the full thrust times the cosine of the angle.
It's basic trigonometry.  The component of a force along an axis is proportional to the cosine of the angle it makes with respect to the axis.
It works with any force, not just rockets.  Ropes, for example.  If you've got a 100-pound weight, and you attach a rope to it, and pull straight up on the rope... what tension do you have to put on the rope to lift the weight off the ground?  100 pounds.  But suppose you have a *horizontal* rope held taut (clothesline-style), with you at one end and a friend at the other, and the weight is hanging from the middle, so that there's only a few degrees of "sag" from the weight.  How hard do you both have to be pulling now in order to lift the weight off the ground?  A whole lot more than 100 pounds!  That's because the vertical component of the rope's force goes with the cosine, which will be small if the rope is mostly horizontal with only a little bit of "sag".
Or, another way of experiencing this:  Try hanging from your hands, with your arms straight overhead, for thirty seconds.  Not so hard, right?  Now try to do the same thing but you're supporting your weight by holding your arms straight out to your sides.  That, my friend, is cosine loss. 
 
You are correct, that is wrong understanding.  They only put a slight amount of thrust forward, since most of their thrust is directed sideways (fighting each other) rather than forward.
 
Be careful not to conflate "energy" with "force".
A rocket expends its energy the same place no matter what its situation:  out the exhaust nozzle.
Imagine that you have two rockets that are pointing perfectly equal and opposite each other, so they cancel out.  Where does their "energy" go now, hmm?  Simple:  Out the exhaust nozzle.  Their force completely cancels out, which is why they don't go anywhere.
And if you nudge them slightly, so they're not quite perfectly opposed... then there will be a slight drift to one side because they don't perfectly cancel each other out.  In other words, the cosine is non-zero.
The main source of confusion is that you've focused on "energy" as the concept here-- it's not super relevant.  Rockets are poor choices for talking about conservation of energy, because they expend such huge quantities of it and it's very much not a closed system (that's the whole point!) and the vast majority of the energy goes out with the exhaust rather than moving the rocket itself.
Focus on the force instead, and you'll have a much better picture of what's going on.
Yes, and the force that the soap moves upwards with is much less than the force you're pushing your hands together.  Again, because of cosine loss.  You could squeeze your hands together really hard to try to make the soap squirt upwards... but I could put one little finger on the soap pressing it down, and you wouldn't be able to budge it.  Not because I'm a whole bunch stronger than you, but because you're fighting cosine loss and I'm not.  I've got a better mechanical advantage.
 

Yeah, heat shields tend to go foof at those speeds-- I doubt the inflatable would help you.  The problem is that they're overheating and exploding before they get down to the point where there's enough drag to actually slow the ship any, so adding more heat shields wouldn't really help, I expect.
Reverse gravity assist would probably be your best bet, though at those speeds I'm not sure how much velocity you'll be able to shed.
(Or, even better, set up a better encounter in the first place so you're not coming in at 8 km/s!)