Snark

Also, bear in mind that dV is a complicated beastie.  Circumstances matter.  In particular, it matters a lot whether you're talking about launching from the surface of a planet (especially a heavy-gravity planet like Kerbin) to get to orbit, versus doing orbital maneuvering.
The reason why it matters (and the reason why the answer to "what's best?" is a complex "it depends" rather than a simple one) is because of gravity losses, which affect planetary launches but not orbital maneuvering.
Explanation in wall of text below, but what it boils down to is this, if you're trying to maximize your dV:
For maneuvering in space, you generally want the lowest possible TWR you can get away with. For lifting off the launchpad on Kerbin, you generally want a TWR of around 1.5 off the pad, but less than that for your 2nd and later stages.  
Okay, on with the details:
When you use your engines, what are you doing with them?  Specifically, are you using them to fight gravity (e.g. when you're accelerating straight up upon Kerbin launch)?
If you're not fighting gravity (e.g. you're in circular LKO and doing a prograde burn)... then your TWR is completely irrelevant to your dV.  All that matters is your engine's Isp and the mass fraction (i.e. fuel percentage) of your rocket.  (You can see this in the rocket equation for calculating dV:  there's nothing there at all about thrust, it's irrelevant.)  Therefore, the best dV generally comes with very low TWR, for a couple of reasons:  first, the highest-Isp engines generally have very low TWR; second, you typically want as few engines as possible, since they're dead weight that counts against your dV. If you are fighting gravity (e.g. you're ascending straight up after KSC launch), then your TWR matters.  This is because every second you're ascending straight up, gravity is sucking 9.8 m/s out of you (on Kerbin, anyway), which is dV that's just flushed down the toilet.  This is called "gravity loss" and is a huge hit to your fuel economy when gravity is strong.  The only way to get around it is to minimize the time you spend fighting gravity (i.e. quickly get up above the thick part of the atmosphere, so you can tip farther over to the horizontal and spend your fuel in actually accelerating your rocket rather than fighting gravity), and the only way to accomplish that is with a high TWR. So, for a launch from Kerbin, it's a balancing act.  On the one hand, you want to minimize gravity losses, in which case you want a high TWR-- the higher the better.  On the other hand, the rocket equation still applies to you (engines are still dead weight), so if you go too nuts with an overpowered ship, then you'll be wasting so much mass on engines that it more than offsets the benefit from reduced gravity loss.  Furthermore, there's another practical limit:  the faster you go while you're in the thick part of the atmosphere, the more energy you waste fighting aerodynamic drag.  If you go faster than terminal velocity on ascent, then the loss to drag outweighs the benefit due to decreased gravity loss.  This sets a practical upper limit on your speed, which in turn means it's not useful to have too much TWR, you'd just waste the capacity.  (Sort of like saying, it's not worthwhile driving a Lamborghini if you're going to be driving around city streets where traffic prevents you from going at high speed.)
In other words:  for liftoff, you need a happy medium in terms of TWR.  Too low, and you waste too much dV on gravity losses.  Too high, and you're lugging too much dead weight and wasting too much dV on aerodynamic drag.
So, I hear you ask, just what is that happy medium?
Answer:  It depends on your ship design (specifically, how big it is and how aerodynamic it is), but typically it's in the neighborhood of 1.3 to 1.5.  (Personally, I prefer 1.5.)  The more aerodynamic the ship is, the higher the TWR it can get away with.  Very large ships (i.e. multi-hundred-ton behemoths) can generally get away with a higher launchpad TWR, because they're less affected by aerodynamic drag and it's therefore worth their while to get up to speed faster.
Also, bear in mind that you don't want high TWR all the way up.  You need it off the launchpad to fight gravity, but pretty soon you're going to be tipping over into your gravity turn, and going less vertical and more horizontal.  Once that happens, a smaller fraction of your rocket power will be spent fighting gravity, which means you'll be wanting a lower TWR to get better dV efficiency.  So, typically, you want your 1st stage off the launch pad to have a high TWR (e.g. 1.5), then your 2nd stage usually kicks in when you're already tipped over 45 degrees or more and can be considerably lower TWR (e.g. in the 1 to 1.3 range), and your 3rd stage should generally be pretty low (is fine to be under 1).

Agree with the prior comments about the value of Oberth effect and doing your burn down low.
Generally, you start your preparation when you're still very far away from the target planet (so that you can use a tiny burn to make big adjustments to you trajectory past the planet), i.e. at least several days before you even enter its SoI.  What you do is to adjust your trajectory so that it has the lowest Pe you can manage without actually scraping your toes.
Then you do your capture burn there, really low, practically at the surface.   Burn retrograde until you're captured, keep burning until you have lowered your Ap down to where you want your circular orbit to be.
Then you coast up to Ap and do a moderate prograde burn to circularize there.

So, a mission to Duna and back will depend on exactly what your objectives are.  For example, if you just want to do a crewed landing on Duna and then return to Kerbin, the mission will look like this:
Get to low Kerbin orbit. Eject to interplanetary Duna intercept. Arrive at Duna.  Either slow to orbit and then land, or land directly. Having landed at Duna, take off and get to Duna orbit. Eject to interplanetary Kerbin intercept. Arrive at Kerbin, reenter, land. So, there are various ways to do these things.  The way you design your mission is to start at the end of the mission and then work backwards.  On each step, evaluate how much dV it needs, and then design your rocket to have that much dV.
For example, start by designing a Kerbin reentry capsule (step 6).  With a lightweight capsule and a good heat shield, no dV required; just let aerobraking do your work for you.
Now add a stage below that that has enough dV to do an ejection from low Duna orbit to get to Kerbin (step 5).  The amount of dV needed depends on planet alignment.  There are tools out there for this-- my favorite is http://ksp.olex.biz, which will tell you what the launch window looks like and how much dV you need.
Then below that, something that has the dV to get to low Duna orbit from the surface (step 4).  This is typically around 1200 m/s, if I recall correctly.
Next, add design to your Duna lander so that it can arrive and land on Duna (step 3).  There are various ways to do this, but I'm a big fan of aerobraking for Duna; play your cards right and you need practically no dV for this.  Heat shield, drogue chutes, regular chutes.  Don't need many parachutes-- just enough to slow down to a few dozen meters per second, then use a last-minute burst of engine thrust to cushion the landing.
Then a stage below that with the dV to get from low Kerbin orbit to Duna (step 2).  You can use the launch planner linked above to get the dV for this.
Then, finally, put a booster on that package that will get it to LKO from the surface (step 1).
So... that's it for your mission planning.
The flip side of the coin is "Okay, so I have a payload like this and I need N meters per second of dV, how do I design that?", which is another issue.  However, I'm not sure where your uncertainties lie-- so let's pause here for a moment.  Does the above get you what you need, or do you still have questions?

I see that you already have some fins on your center stack, so it's good that you're making some effort at aero stability.  But the likely culprit here is that it's simply not stable enough.  Rather:  without the landing legs on, it's OK but marginal.  Adding the high-drag landing legs up near the front of your stack may be enough to push it over the edge into instability.  The fact that you have non-gimbaled engines and therefore have very little control authority makes the problem even worse.
A few suggestions, in no particular order:
Replace at least some of those Reliants with Swivels instead.  The Swivel has the ability to gimbal, which will help maintain your stability when SAS is turned on.  If you choose to use a mix of Reliants & Swivels instead of going 100% Swivels, then the Reliants should be the first engines that you stage away, since the Swivel has superior Isp at low atmospheric pressure.  At the very least, the engine on your center core should absolutely be a Swivel rather than a Reliant. Move the asparagus tanks down.  Way down, as far as you can go.  As they empty out, your CoM will move upwards, which will help your stability. Add more (or bigger) fins. Make sure that your landing legs are retracted during launch; they have less drag that way.  (I bring it up because they look extended in one of your screenshots.) Looks like you have a stack of 2-ton tanks in the middle.  Be advised that using a stack of tanks tends to cause stability problems, because the stack drains from the top down, which moves your CoM radically downwards and kills your stability.  Suggest using a single 4-ton tank instead, with a 2-ton tank on top of it which is disabled initially so it won't drain.  You can then enable that top tank when the 4-tonner beneath it is mostly empty.

Nope.  If there are files there that it doesn't recognize, it leaves them alone.  All it does is make sure that,
if there's an "official" file that's missing, it restores it if there's an "official" file that's been altered, it overwrites it with a fresh version This saved my bacon when I'd been tinkering with some stock textures and accidentally overwrote the actual installed file rather than the copy I had made in my own, separate folder.  It was quick, easy, and worked perfectly.
 

Just to elaborate on the above:  The semantics of how transmission-versus-recovery works can be a little confusing if you're not used to it.  Here's the deal:
Each experiment type has a "transmission cap", expressed as a percentage.  Typical values are 45% or so.  Some are significantly lower.  A couple of them (EVA reports and crew reports) are 100%. The transmission cap represents the maximum points you can get by transmitting, ever. It's worth talking through a sample scenario so you can see how it works.  Let's say you have a science instrument with a transmission cap of 45%.  Let's say you're in a place where the full value  (i.e. if you recover it) of a measurement is 100 points.  Here are some scenarios, and what happens in each:
You take a measurement.  Later, you recover the craft at Kerbin. Result:  You get 100 science points at recovery time. You take a measurement.  You transmit the science. Result:  You get 45 science points as soon as transmission is complete. You've previously taken a measurement and transmitted it.  Now you take another copy of the exact same measurement, and transmit it again. Result:  You get 0 science points. Reason:  There were a total of 45 points' worth of transmittable science for this experiment in this situation.  You already got those the last time you transmitted them.  So there's nothing left; transmitting the same thing again gets you nothing. You've previously taken a measurement and transmitted it.  Now you take another copy of the exact same measurement and physically recover it on Kerbin. Result:  You get 55 science points at recovery time. Reason:  There were 100 points' worth, total, available for this experiment for this situation.  You already siphoned off 45 of them when you previously transmitted the result.  That leaves 55 points remaining, available to you, which you can get by physically recovering the craft. Sounds like you're running into situation #3 here.
Useful science strategies in KSP tend to fall into two categories:  return missions (where you physically recover the craft), and non-return missions (where you transmit science but the craft's on a one-way trip to space).
For recovery missions, you can either go for scenario #1 or scenario #4.  Both give you the exact same total benefit at the end of the day.  In my own games, I tend to go for #4; it doesn't give me any more total science, but it lets me get around half of the science immediately upon acquisition, without having to wait until I recover the craft, which can be helpful when I'm climbing the tech tree.
For non-recovery missions, #2 is the only practical option, since #3 doesn't get you anything. 

Regarding the landing gear: try putting larger gear on the plane. You may have too much weight on too-small gear. The gear are no longer indestructible, the way they were pre-1.1, and size matters.
As for your flight instability issue, a screenshot of your plane would help.

Specifically:  Every control surface can be individually toggled to control pitch, and/or yaw, and/or roll.
By default, all of these are on for every surface.  This can be bad.
In particular, it's really important for the vertical stabilizer on the tail.  You should make sure that it's set to yaw only, and does not have roll authority enabled.
Reason:  If you've got roll authority turned on for the vertical stabilizer, it will deflect left or right whenever you try to roll... and that will make the plane yaw.  And then it ends up fighting itself.
General best practice:  go through every control surface on the plane, look at it and decide "what do I want it to do?" (i.e. which of pitch, roll, yaw), and turn off anything that you don't want it to do.

Moving to Gameplay Questions.
Also, the answer is Alt+F12.

Yah, it's a good idea to be really judicious about what contracts you accept until you can raise the 30-part limit.  Orbit's perfectly doable, and reasonably profitable in early game.  Fly by the Mun, also doable.
In my own career games, I've found that boosting the launchpad is a handy early upgrade-- it's a lot cheaper than upgrading the VAB.   And it lets me use whacking great SRBs, which in turn lets me loft more rocket while keeping the part count low.
I use suborbital/orbital tourist contracts a lot in the very early game as a handy reputation builder to unlock more useful contracts.  Once I get far enough along that I can get to Mun/Minmus without awkward ship-design gymnastics to deal with low tech and/or part limits, though, I tend to taper off and avoid tourist contracts-- the payoff is terrible, in terms of reward per hour of my time.  They tend to be extremely time-consuming contracts that don't actually pay a huge amount of money, so they quickly turn into a really tedious grind for me then; I switch to other contract types.

If you're talking about copying parts in the VAB, what exact sequence of operations are you doing?  It should go like this:
Press and hold the ALT key. While holding it down, then click the mouse on the part (or tree of parts) that you want to copy. Note, that's click, not "drag".  Don't try to "drag" the parts out.  Just click and release the mouse button.  It'll create a cloned copy that's attached to your mouse cursor. You can now let go of the ALT key and move the cloned parts where you want. Does that not work?
 

The answer is basically, no, that's not possible.
There are a few moving parts that people have come up with original uses for.  For example, I've seen rover designs that have a pair of heavy-duty landing legs on the top side, normally kept retracted, so that the rover can use them to flip itself right-side-up again if it flips over.
I've also seen some crazy contraptions where people built "bearings" made of lots of airplane landing gear, mounted around a central axis, so they could get a rotating part.  But these weren't really "natural" machines, they were clever hacks to achieve a specific type of motion on an awkwardly-shaped vehicle.
To be able to have the kind of motion that you describe, in a simple controllable way on a nicely usable part-- no, that's not possible in stock.  A lot of people have wanted that for a long time.    Maybe someday, but until then, you'll need a mod (like Infernal Robotics) to do something like that.

In a career game, they show up based on the "piloting level" of your ship.
With a level 1 pilot, you get the retrograde/prograde buttons.
With a level 2 pilot, you get normal, antinormal, radial in, radial out.
With a level 3 pilot, you get target / anti-target and hold maneuver.
...The same deal applies to probe cores, too-- higher-level probe cores act like higher-level pilots.  For example, OKTO acts like a level-0 pilot, HECS like a level-1, OKTO2 like a level-2, and the 1.25m-and-bigger cores like a level-3.

Your problem is that your re-entering spacecraft is lawn-darting.  It's too aerodynamic in that nose-first configuration, and it's so stable (with the pointy nose and the fins on the back) that you probably can't make it enter any way other than nose-first, amirite?
If you could fly that ship sideways, then atmospheric drag would be plenty to slow it down well below 250 m/s long before it hits the ground.
Even if you can't go fully sideways, if you could just steer it some to keep the nose about, say, 30 degrees above prograde, then body lift will keep your descent shallow and you'll go nice and slow.
Have you unlocked any steerable fins, such as the AV-R8 winglet?  If so, put a pair of those on the left and right side of the reentry ship, in place of the Basic Fins.  That will give you enough steering ability on the pitch axis that you can nose-up and slow down a lot.
That might not help much in this case-- his problem is that he's lawn-darting, and eliminating that heavy engine on the back will just make his reentering ship even more nose-heavy and could make it even harder to get out of "prograde lock".  I suspect that steerable fins would help a lot more.
That might also not help a lot.  The ship is really aerodynamically stable nose-first, not tail-first, so I suspect that even if he enters retrograde, there's a high likelihood that aero forces will wrench the ship around prograde as soon as the atmosphere starts to get thick.

Rovers eat a lot of electricity.  Are you planning on doing long cross-country journeys where you go halfway around the planet, or just pootling around a few kilometers?  If it's the former, you need to make sure that you have enough electricity to run continuously at full power.  If it's the latter, you don't need so much electricity generating capacity, as long as you have a reasonable amount of battery storage.
I usually power my rovers solar-only (unless I'm out beyond Duna where solar = teh sucks). PB-NUK is fine, but you'd need a lot of them to do continuous full-power rover exploring.
My usual rover designs for vac worlds have a few of the retractable 1x6 solar panels mounted in a V shape, tilted about 30 degrees above horizontal to keep them well clear of the ground for when I may tumble a bit.  For worlds with an atmosphere, I tend to use a fair number of OX-STAT panels on the back of the rover, so that I can keep generating some electricity even when in motion... but I still include a couple of the retractables, which I can extend when I stop in order to charge up more rapidly.
Your main concern with breaking wheels is not going too fast as in "I went over 60 m/s and they can't handle that much", but rather the bumpiness of terrain:  hitting a sudden speed bump can break your wheels even if you're going fairly slow.  It matters a lot how smooth the terrain is, which varies a lot from planet to planet.  If you're on the Minmus flats, knock yourself out.  :-)  Otherwise terrain is a concern.
Another wheel-breaking worry besides just how bumpy the terrain is, is how massive your rover is, i.e. how many tons per wheel.  More massive rover = more inertia = more strain on the wheels when you hit a bump = more likely to break.  If you have a very lightweight rover, wheel breakage is much less of an issue than with something massive.
The "ruggedized" wheels you get at tech 550 are a lot more breakage-resistant than the simple ones you get at tech 300, so use those if you possibly can.  The fragile ones are certainly usable, but you have to baby them a lot more. In particular, your effective max speed over terrain will be lower for the low-tech wheels, because you'll have to go slower to avoid breaking them.
When placing wheels, make sure you give yourself plenty of ground clearance-- your rover body will "sink" quite a bit when the suspention bottoms out as you go over rough terrain, and you don't want anything other than wheels to touch the terrain while you're zipping over it.  In other words, if you're using a cylindrical 1.25m rover body, don't mount the wheels directly on the left and right sides like a lizard's legs; you want them a bit underneath.  I usually mount my wheels radially about 45 degrees below the left and right sides, then use the rotator widget to adjust the wheels so that their axis is parallel to the ground.
Incidentally:  All of the above advice is based on 1.0.  From what Squad has said in their devnotes, apparently wheel physics will be getting a major overhaul in 1.1 due to the Unity engine change, and I have no idea what the experience will be like in 1.1-- about the same?  more breakage-prone? less breakage-prone?  No clue.  So take all this advice with a grain of salt until 1.1 is out and there's more data on what the experience is like.
One absolute must have for a rover:  put a headlight on it.  The long-range spotlight, not the short-range floodlight.  You need to be able to see where you're going, bumps can kill you.  Without a headlight, you basically have to sit around doing nothing any time the sun is lower than about 15 degrees above the horizon, 'coz you just can't see where you're going.
If you're roving on Eve, I suggest putting some stubby fixed wings on the left and right sides of the rover.  Doesn't need to be a lot.  You can glide suprisingly well-- enough to land with when descending from space, for example, and when you come to a steep downslope you can glide there, too.
 
That should work pretty well.  I'm a big fan of the structural fuselage-- light, stiff, strong.  Gives you some wheelbase to make it less likely to tumble.
Top speed is about that, yes.  Tires will definitely blow over 60 m/s, even if you're on perfectly level ground.  But in practice, if you're going over anything but Minmus flats, you're going to have to go way slower than that.  Bumps in the terrain smack hard.  In practice, I find going faster than 18 m/s is very risky unless I'm watching the terrain like a hawk and ready to slow down any time there's an irregularity.  If you have heavy loading per wheel, the safe limit may be lower than that.
Also:  it takes forever to get anywhere in a rover, so you'll find yourself wanting to use physics warp to speed things up.  It does... but it also makes your rover more fragile and tires more likely to pop, so your safe speed limit will be somewhat lower in m/s if you're running with physics warp.
That works.  Actually, for small science rovers, what I like to do is not bother with a skycrane, and just put a little engine (like a Spark) on the rear of the rover, with a small fuel tank like an Oscar.  The small amount of weight doesn't bother the rover much, when it's landed.  The rover just lands itself, coming down tail-first to a soft landing, then rotates down to the horizontal.  Simple, easy, lightweight.  It also can be handy when you get into a region with steep hills and can use a bit of a rocket boost to go up.  Or if you're running around at high speed on a low-grav world and accidentally go flying off a hill crest, and fall a long way, and are plummeting wheel-breakingly fast towards the surface; you can use a rocket assist to slow down.
(I actually like to put a taillight on my rovers like this, and then in the "Action" tab of the VAB, I deliberately take the taillight out of the "Light" group and put the light into the "Gear" group.  That way, the light serves as my "landing gear" to provide a visual reference when landing, extremely helpful in gauging my distance from surface when I'm on final approach.  And it toggles on/off separately from the headlight, which is in the Light group.)
 

Welcome to the forums!  You're totally in the right place. 
A couple of things:
First, disable roll authority on your tailfin-- right-click on it, you want it to be doing nothing but yaw.  This will help your stability and make it more effective at yawing. You're slow to roll because the elevators on the tail don't have much torque-- they're close to the center axis of the ship.  Try putting some ailerons out on the wingtips, it'll give you lots of roll authority.

The easiest and least-intrusive-to-your-existing-design way might be to just put a fairing around them. Stick a 2.5m fairing base under the drills, in between that 1.25m decoupler and that 3.75m heat shield.  Build the fairing up so that it closes around the ore tank just above where the drills are.  Set up the staging so that you pop the fairing just before you activate the decoupler (i.e. after the hot part of reentry is finished).

What you're doing is an Oberth maneuver.  Unfortunately, Pol is poorly placed for that.
An Oberth maneuver is good for getting into a very low circular orbit-- for example, if you wanted to end up in a circular orbit just above Jool's atmosphere, you'd want your Jool-approach periapsis to be down there and do your whole burn at periapsis.
An Oberth maneuver is also good for getting into a very high circular orbit-- for example, suppose Pol had an orbit that was waaaaay up near Jool's SoI boundary, where orbital velocity is only a few meters per second.  In that case, an Oberth maneuver would work great:  you do your capture burn at a very low Jool periapsis, putting your apoapsis right out by Pol.  Then when you coasted up to Ap, you'd have only a very small and cheap circularization burn (since the orbital velocity is so slow up there).
What Oberth maneuvers are not good at is in-between circular orbits, which is where Pol is.  If you dive low enough to Jool to get a decent Oberth effect for your capture burn, then your resulting ellipse (with its apoapsis at the target orbit) will be so eccentric that you'll have to do a big circularization burn to match orbits.
Now, one thing you can do that can give you quite a boost is a gravity assist maneuver, using Tylo or Laythe.  The idea is to use the heavy moon's gravity in a sort of "reverse slingshot" to slow you down enough to capture to the Jool system even without using any rocket power at all.
An example of such a maneuver:  approach Jool in such a way that your descending orbit (on your way to Jool Pe) passes right in front of (not behind!) Tylo, with the lowest possible Tylo periapsis that you can manage.  This will cause Tylo's gravity to slow you down.  You'll also take advantage of a mathematical inaccuracy of patched conics, in that you will re-enter Jool's SoI (from Tylo's) at a much lower Jool altitude than the point at which you entered Tylo's SoI, without having actually fallen that distance in Jool's gravity and thereby picked up more speed.
Since you're passing really low to Tylo, you can give it a double-whammy by doing a retro-burn at low Tylo Pe to further slow yourself down, if necessary (e.g. to fine-tune your resulting orbit to put your Ap out by Pol), thus taking advantage of Oberth effect at Tylo rather than Jool.
 
 

Okay.  So, yes, it's a light and fluffy payload, which is exacerbating your problems.
My advice:  Lose the fairing.  You're getting virtually zero benefit from it.  Your payload is already fairly streamlined, with just a few radial parts sticking out.  And with a rocket as huge as yours is, it's not even going to notice the drag from a few landing legs and solar panels.  Replace that short conical adapter with the taller one, so that it'll be more streamlined.  Rotate your Gigantors so that they're in the default vertical orientation, rather than horizontal, so that they're  more streamlined on ascent.  Ditch the fairing entirely.
(Do you have the tech for an RTG?  If so, put on a couple and ditch the Gigantors entirely.  Solar panels really suck, out by Jool.  You get more power-per-mass with an RTG, out there.)

+1 to @Veskenapper's advice.  As long as you have "enough" thrust (e.g. a local TWR of, say, 3 or so on the Mun-- i.e. about 5 kN of thrust per each ton of ship mass), you'll do fine.  Isp is much more important, as you've discovered (with the nukes).
One way you can help fuel woes is to use more specialized equipment.  Lugging around extra mass just kills you.  For example:  Suppose you put a fuel depot in orbit around the Mun.  Doesn't have to be anything big or fancy, basically just a big empty fuel tank (plus a tank for monopropellant, Karbonite, and/or whatever other resources are important to you).  Equip it with a fair number of docking ports of various sizes.
Then you could have a specialized Karbonite-miner that has nothing but Karbonite drills & refining equipment.  It doesn't waste mass on other equipment it doesn't need.
And a specialized science lander that could be very small and light-- basically just a Mk1 lander can, two tons or so of fuel, a single Terrier or couple of Sparks, all the science instruments, nothing else.  You could build the whole thing for around 3 tons including fuel.  It can go hop around quite efficiently with very low fuel usage.
By having a family of specialized vehicles for different purposes, you're a lot more efficient because you don't lug around mass you don't need on a particular sortie.  For example, a single refueling run by your Karbonite miner might provide enough fuel for your science lander to hop to half a dozen different biomes, with refueling stops at the depot.
Anyway, just a thought. 

I don't have KSP in front of me right now, so can't test, but I'm not super surprised.  I doubt that it's deliberately designed behavior, so I seriously doubt that there's a config setting for it. Sounds more like a bug, and unless they've specifically targeted it for 1.1, I expect it'll stick around.
Unless someone tells them about it... hint, hint. 
We have no way of knowing what the game's internal code is doing, of course, but if I had to guess, I'd suppose it's probably something like this:  The external command seat has been part of the game for a long time-- it was around long before all the nifty Porkjet spaceplane parts arrived, with their fancy cargo bays.  So back in the dim mists of ancient time, whatever programmer was creating the command seat was operating in a universe where cargo bays did not exist and it was not physically possible for one part to be inside another (hollow) part.  So "make the kerbal just snap to the top of the ship" may have made perfect sense, then:  it's simple, it's fairly intuitive, maybe it neatly solved various troublesome potential edge cases.  And then, much later, Porkjet's stuff came around, and it may be that simply nobody thought to look at that particular interaction, and a solution that used to make sense suddenly no longer did so.
It's the kind of thing that happens all the time in software development:  bugs creep in not because any one person did anything stupid or foolish or absentminded, but because there are so many different moving parts all talking to each other that it's very easy to miss when the addition of a new element of a system makes a new type of interaction possible that nobody thought about.
TL;DR:  software is hard. 

Yes or no, depending on what you mean by "strength."
The stiffness of a docking connection is a lot lower-- it's "floppy," easy to bend. Bigger docking ports are stiffer than smaller ones, but they're less stiff than a regular joint.
However, as far as I can tell, the tensile strength (resistance to being pulled apart) is as strong as a regular joint.

From the standpoint of torque authority, it doesn't matter where you put the SAS.  They will have exactly the same effect on rotating your ship, regardless of where on the ship they're located.
That said:  if you have wobble problems (big, flexible ships) then it can make a difference about where the wobble is.  And any time you have multiple short things in a stack (like batteries, SAS units, whatever), that adds a lot of joints that can bend which in turn greatly contributes to wobble.
It's why I really prefer to mount my tug engines radially.  It means I can put the reaction wheels on the radial stacks, which means that my central stack has very few parts in it and is therefore nice and stiff.  Also, the engines tend to be the heaviest parts of the tug, and by mounting them radially, they can be considerably farther forward than they would if they were mounted underneath.  This means that my tug has a much smaller moment of inertia around the forward docking port, which means it's less prone to wobble at the docking-port connection (docking ports aren't particularly stiff when connected).
The TT-70 radial decoupler makes a great "stand-off" mount for radial stacks.  Lightweight.  Available early in the tech tree.  Just click its "disable staging" button in the VAB when building, so you won't accidentally use it for the purpose for which it was intended.    Put a big LF-only tank in the middle (the Mk3 parts are useful for this), with a quartet of TT-70's sticking out the sides, and then on each one you put one of the little 1.25m LF tanks with an LV-N on the bottom and a reaction wheel or two on the top.  Attach a single strut to help keep it stiff.  Add fuel lines.  The top of the radial stack is a handy place to put a battery, and the sides of the radial stack are useful for mounting radiators to keep the nukes from overheating.
The radial stacks arealso a handy place to put some floodlights for self-illuminating (useful when docking).
Not sure what you mean by "doing to" ... "put fuel in them" is about the most I have to offer. 
I like to use the biggest possible tanks.  It saves tedium by reducing the number of trips I have to make, and also saves lag by reducing part count.
For fuel transfers, I tend not to use a dedicated tug with a separate tank.  Instead, I make a "tanker" orbital ship which is a couple of really big fuel tanks with some radially attached LV-N's and a few docking ports.  Put one in low orbit around wherever I'm getting my fuel from, use dedicated fuel lifters to move the fuel from the surface to orbit, transfer the fuel, then move the tanker to wherever it needs to go.  I like to do this because orbital tankers and fuel lifters have different needs (in particular, the latter has to care about TWR a lot more than the former does).
By the way, if you're doing bulk transfer of stuff like fuel, you may like to check out the SpaceY Heavy Lifters mod.  Really excellent parts pack.  It includes really big tanks & engines (including 5-meter parts), plus lots of useful utility parts, such as 3.75m and 5m docking ports, and radially-attached high-torque reaction wheels for 3.75m and 5m stacks.
Also... just out of curiosity, any particular reason to choose keosync as the altitude for your big station, as opposed to LKO?  Misses out on a lot of Oberth benefit, and is expensive to come home from as well as to get to.  I find that (for me, anyway) LKO is a lot more useful and fuel efficient.  "What's the 'right' space station altitude" is one of those hot KSP topics with no one "correct" answer, it's just that I'm always curious about people's reasons when I read about a playstyle different from my own. 

It's light and draggy in the front It's using vertically stacked tanks It doesn't have any torque authority Fix those three things and you're good. 
Light and draggy in front:  You want your CoM to be as high as possible, and you want to be streamlined in the front.  That means you really want to avoid any big, low-mass parts at the top of the rocket.  For example, you have those paired conical adapters on there.  I assume you're doing that because they "look cool"?  (I can't tell that they have any functional purpose.)  Those things are killing you; they're big, they have a lot of drag, and they're very very light.  So just get rid of them.  As it stands right now, trying to keep your rocket nose-first is like trying to throw a dart backwards.
Vertically stacked tanks:  The problem with having fuel tanks stacked on top of each other is that the engine drains the top tank first, which causes your CoM to be catastrophically lowered and screws up your stability.  The ideal way to fix this is to replace the stack-of-little-tanks with a single taller tank.  I'm guessing that the reason you're not doing that is that this is a career game and you haven't unlocked the taller tanks yet?  In that case, here's a workaround that ought to help you:  in the VAB, disable all the tanks except the bottom one.  This will force the rocket to drain the bottom tank first (since it's the only usable one), which will improve your CoM rather than making it worse.  It does mean that your rocket will conk out as soon as it drains that tank, so you'll have to watch the tank and enable the one above it as soon as it's almost empty, so that you won't have any interruption of thrust.
 
No torque authority:  There are only three ways to turn a rocket in KSP.  1. Gimbaled engines, 2. Aerodynamic steering with control surfaces, 3. Reaction wheels.  You don't have any of those.  Your liquid-fueled engine is a Reliant (no gimbal), and the SRBs have no gimbal either.  You have static fins that can't steer.  And you don't have any reaction wheels.
Suggest replacing the Reliant with a Swivel (it has gimbal), and add a reaction wheel (the 1.25m one should be fine).  Those by themselves may or may not be enough-- aero forces tend to dominate during the high-speed phase of ascent.  So you may need to replace your fins with steerable ones, such as the AV-R8 that @Stone Blue suggests.

Okay, that's seriously cool!
Not sure to what degree KSP has the full aerodynamic complexity and/or physics modeling to accurately capture how a helicopter behaves.
Real helicopters are controlled by altering the pitch of the blades.
https://en.wikipedia.org/wiki/Helicopter_flight_controls
The pilot's controls are a cyclic (big joystick, this is the primary control) and a collective (a lever like the handbrake of a car).
The collective controls the net pitch of all the blades; "give it more collective" and all the blades are pitched steeper, = more lift.  This is used to control the up-down motion of the chopper (i.e. direction parallel to the main rotor axis).
The cyclic is more interesting.  It uses a clever mechanical arrangement to alter the pitch of the blades by different amounts based on what angle they're at, as they spin around.  So if you want the chopper to move forward, you push forward on the cyclic.  This causes the blades to have steeper pitch when they're at the back of the chopper and shallower when they're at the front, as they spin around, so that the rear part of the "rotor disk" is generating more lift than the front, the chopper noses down, and it scoots forward.
Helicopters also need a way to control yaw (i.e. roll around the main rotor axis).  This is typically a pair of pedals that you can push left-or-right to yaw left-or-right.  For conventional choppers, this controls the tail rotor (I assume blade pitch).  I dunno about coaxial choppers, but I would assume it would apply differential pitch to the clockwise-versus-counterclockwise rotors to achieve the same effect.
As to why your chopper isn't behaving as expected when you nose it forward:  no clue.  I would guess that it has something to do with the disparity between KSP's fairly simplistic aero modeling and real world aerodynamics.  Just out of curiosity, have you tried flying it with FAR?  Any difference?