OhioBob

The current version of Transfer Window Planner works with KSP versions newer than 1.7.  I've used it all the way up to at least KSP 1.11.  Just because the mod hasn't been updated doesn't mean it won't work.  Mod authors often don't bother updating when there's no need to.
There's also an online version that you can use:  KSP Launch Window Planner by alexmoon
 

You're already in orbit, albeit an elliptical one with a periapsis inside the atmosphere.  Just raising the periapsis out of the atmosphere doesn't take all that much delta-v.  For instance, let's say that after aerobraking you are in a 50 x 200 km orbit.  Burning at apoapsis to circularize into a 200 km orbit takes only 112 m/s.  Even less if your apoapsis is lower.  You're probably saving close to 700 m/s by aerobraking.
 

@Zosma Procyon, there are a lot of variables that go into it.  I don't like using delta-v maps for it.  Delta-v maps are probably OK for ascent, but I think they underestimate descent.  On ascent you just hit the throttle and go, but on descent you have to approach the surface more slowly and with caution.  This means fuel is burned effectively hovering.  It can be minimized with a suicide burn, but some people prefer a stop-and-drop method.  I generally do what is sort of a hybrid.  I'll do a burn to lower my periapsis to maybe 5-10 km over the landing site (low as I can while assuring I don't impact any mountains).  At periapsis I do a big burn to kill most of my velocity.  Then when I have descended to about 1 km altitude, I kill most of my remaining velocity and slowly drop to the surface.  This isn't the most efficient, but it's not the worst either.
Several years ago I plugged a bunch of numbers into a spreadsheet to compute how much delta-v this method used for each of KSP's airless bodies.  I was somewhat conservative in my numbers, and included an extra 30 seconds of hover time to play it safe.  Even still, there are many things that can change the results, like height of initial orbit and TWR.  Nonetheless, the numbers form a basis for budgeting delta-v.
Moho - 1300 m/s
Gilly - 45 m/s
Mun - 885 m/s
Minmus - 275 m/s
Ike - 595 m/s
Dres - 615 m/s
Vall - 1260 m/s
Tylo - 3360 m/s
Bop - 320 m/s
Pol - 210 m/s
Eeloo - 915 m/s
Landing should definitely be doable using these numbers.  But even this might not be enough if you are really inefficient.
 

Yes, look in the KSP Wiki (link at the top of the forum).  Each planet has a table that gives pressure vs. altitude.
 

While I agree that in real life a body's datum is placed close to its mean surface elevation, it is customary in KSP to place the datum at the point of lowest surface elevation.  I'm not sure why that decision was made, but we're pretty much stuck with it.  Placing the datum at the mean surface of course means that much of the surface will be at negative elevation.  This results in problems the way that KSP is currently coded.  While I've heard rumors of certain problems, the only issue that I've personally observed is with the radar altimeter in IVA mode.  The radar altimeter is suppose to display height above terrain.  It works correctly when the terrain elevation is positive, but when negative the altimeter displays the height above the datum rather than the terrain.  This makes the altimeter worthless when landing at a site that lies at negative elevation.  The same problem exists with the "height above terrain" readout in KER, and I'm guessing MechJeb as well, though I haven't tried it.  I presume these mods simply get the altitude from KSP.  It seems that in order to use negative elevations effectively, KSP needs to change.
 

I haven't seriously studied this issue, so I can't say with certainty what is optimal.  However, a typical interplanetary transfer orbit looks something like this:

So I think it would be best to launch into a parking orbit that is inclined in the same direction as your eventual interplanetary transfer orbit.  That means the line of nodes should point toward the Sun (or at least as close as you can make it).  To achieve this you want to launch into the parking orbit when KSC is on either the prograde or retrograde side of the planet, depending on the inclination of the transfer orbit and geographic location of KSC.  For the orbit transfer shown in the figure above, and assuming KSC is located in the northern hemisphere, then you want to launch when KSC is on the prograde side.
That's my 2¢ anyway.  I make no guarantees that there isn't a better way of doing it.
 

Kerbin's ocean bottom is really just a flat plain with a noise function.  It's therefore sprinkled with a bunch of high and low points, with all the highs being about the same, and all the lows being about the same.  However, there's enough variability that some spots are lower than others.  I extracted a heightmap and used Photoshop to located three candidate spots (represented by the black pixels in the heightmap).  I then used a SCANsat altimetry map to zoom in on those three locations and scan for the lowest elevation.  I think I found it at -1393.5 meters, 27.07o S latitude, and 79.00o W longitude.

I would say a flyby is anything that enters a body's SOI, passes through periapsis, and the exits the SOI.  The vessel's trajectory in relation to the celestial body is hyperbolic, meaning it has an eccentricity >1, a semimajor axis <0, and no apoapsis.  Only a closed elliptical orbit can have an apoapsis; a hyperbolic orbit is an open or unbounded orbit.  You might see an apoapsis outside the SOI, but this is the apoapsis of the vessel's orbit around the sun (or around the planet if we're flying by a moon).  When inside the SOI we see the hyperbolic geocentric orbit, and when outside we see the elliptical heliocentric orbit.
Because of the way KSP does patched conics, there could be the unlikely scenario in which a vessel passes through a body's sphere of influence while not actually being on a hyperbolic trajectory.  That is, it could have an eccentricity <1 with an apoapsis so far away that it's outside the SOI.  However, for any kind of normal interplanetary encounter, the vessel will be carrying enough excess velocity that the chances of this happening is nil.
As far as contracts are concerned, I think we just need to enter a body's sphere of influence.
 

Yep, that's normal.  Every planet has what is called a synodic period, which is the time between successive conjunctions of the planet with the sun.  The synodic period is also the time between successive launch windows.  The synodic periods for the stock planets are:
Moho - 135 days Eve - 680 days Duna - 910 days Dres - 527 days Jool - 467 days Eeloo - 453 days This is the same reason why NASA launches missions to Mars about once every two years.
 

You're in luck.  I've written a spreadsheet that automates the process.
 

I can give you a simplified answer.  Ignoring drag and assuming constant acceleration, the equation is
t = (v + SQRT(v2 – 2*z*(g+a))) / -(g+a)
where v is the current vertical velocity, z is the current altitude, g is the acceleration of gravity, and a is the acceleration from the engines.
Suppose we have v = -100 m/s, z = 1000 m, g = -9.81 m/s2, and a = 14.8 m/s2 (upwards is positive).  The time to impact is,
t = ( -100 + SQRT((-100)2 – 2*1000*(-9.81+14.8))) / -(-9.81+14.8) = 19.14 seconds
Note that if 2*z*(g+a) > v2, the equation will fail because you're trying to take the square root of a negative number.  When this occurs it means that the vehicle will stop and start traveling upward before reaching the ground (i.e. too much upward acceleration).
Of course the time to impact is really "time to impact at the current speed, distance, and acceleration".  As long as you make it so the time to impact constantly updates, the closer you get to the surface, the more accurate the calculation becomes.
If you want to take drag into account, that really complicates things.  There's no simple equation in that case.  But if you're only worried about the final moments of a propulsive descent leading to a soft touchdown, you're probably traveling slow enough that drag isn't really an issue.
 

You can launch directly into a 6-degree inclined orbit to match Minmus if you launch at the right time.  These opportunities happen twice a day when the KSC passes through the plane of Minmus' orbit.  I do it it like this:
Send your rocket to the launch pad and then switch to the orbital map view.
Focus your view on Kerbin (double-click on Kerbin to change focus from rocket to planet).
Zoom out until you see the orbit of Mun.
Align the view so Mun's orbit is seen edge on.
Zoom out until you see the orbit of Minmus.
Rotate the view left-right until Minmus' orbit is seen edge on (keeping Mun's orbit edge on as well).
The orbits of Mun and Minmus will now been seen as two intersecting lines.
Time wrap ahead until the launch site reaches the point where the two orbits cross.
Check to see which direction you need to launch to match Minmus' orbital plane, i.e. north of due east or south of due east.
Switch back to the launch pad view and launch.
Immediately after beginning your ascent, rotate the rocket 6.5 degrees either north or south (as determined two steps earlier).
After rotating the rocket, begin your pitch down and fly a normal ascent to orbit.
This should get you pretty close to matching Minmus' orbital plane.  I always have some error but the correction is usually small and easy to fix.

Let's take a look at some sample numbers by considering a flight to Duna.  In an orbit of 100 km, orbital velocity is 2246 m/s and escape velocity is 3177 m/s.  Therefore, from an orbit of 100 km, we must increase our velocity 3177 - 2246 = 931 m/s just to escape Kerbin gravity.  However, if we accelerate to exactly escape velocity we'll have no velocity left over after escaping.  For a typical Hohmann transfer to Duna, we must be traveling about 900 m/s relative to Kerbin after escaping the Kerbin's gravity.  This left over velocity is called hyperbolic excess velocity.  Burning from an altitude of 100 km, we find that we must increase our velocity to 3302 m/s in order to have a hyperbolic excess velocity of 900 m/s (math provided on request).  Therefore we must increase our velocity by 3302 - 3177 = 125 m/s above and beyond escape velocity, or we must provide a total Δv of 3302 - 2246 = 1056 m/s.  We see that we obtain 900 m/s in hyperbolic excess velocity for only a 125 m/s expenditure in Δv.  That's the Oberth effect at work.
Now let's look at the numbers for an ejection from an orbit of 1000 km.  Here orbital velocity is 1486 m/s, escape velocity is 2101 m/s, and, in order to produce a hyperbolic excess velocity of 900 m/s, we must attain a velocity of 2286 m/s.  Therefore, just to escape we must provide a Δv of 2101 - 1486 = 615 m/s, and, to produce the extra 900 m/s, we must provide additional Δv of 2286 - 2101 = 185 m/s.  The total ejection Δv is 2286 - 1486 = 800 m/s.
So we see that takes less Δv to eject from a 1000 km orbit (800 m/s) than it does to eject from a 100 km orbit (1056 m/s).  This is because we are higher up in the gravity well where it takes to less Δv to escape (615 m/s vs. 931 m/s).  However, when we look at how much Δv is takes to produce the 900 m/s hyperbolic excess velocity, we see that it is less from the 100 km orbit than the 1000 km orbit (125 m/s vs. 185 m/s).  This is because the Oberth effect is greater closer to the planet where the orbital velocity is higher. 
Therefore, the answer to your question is, for a hyperbolic excess velocity of 900 m/s (approximately that for a transfer to Duna), the difference in Oberth effect between a 100 km orbit and a 1000 km orbit is about 60 m/s.  Of course you can see that that's not the total story.
As we increase our orbital altitude, the Δv required to reach escape velocity decreases, and the Δv required to produce the hyperbolic excess velocity increases.  If we were to plot total Δv versus altitude, we would see that the Δv initially decreases with increasing altitude, reaches a minimum, and then starts to increase with increasing altitude.  The altitude at which the minimum occurs is called the gate orbit.  The height of the gate orbit is different for every transfer because the hyperbolic excess velocity is different for every transfer.
Of course, if you start out in a low orbit, you would never want to transfer to a higher orbit to perform the ejection.  This is because it takes more Δv to raise the orbit than what you can potentially save on the ejection burn.  In the example above, it takes 730 m/s to go from a 100 km orbit to a 1000 km orbit, while you save only 256 m/s on the ejection burn.  If you are launching into a temporary parking orbit from which you plan to perform an ejection burn, it is almost always best in terms of Δv to make your parking orbit as low as possible.  The only possible exception that I can think of is if you have a really long ejection burn, then there might be some benefit to launching into a higher and slower orbit.
 

Performing a Hohmann transfer to Duna from a solar orbit near Kerbin requires a Δv of about 800 to 1000 m/s.  To this we must add the Δv that it takes to escape Kerbin in the first place, which is about 940 m/s.  This gives a total of about 1740-1940 m/s.  Performing the ejection burn from low Kerbin orbit requires a Δv of about 1050-1100 m/s.  Therefore, you are costing yourself about 690-840 m/s by executing the maneuver the way that you are doing it.
 

If you return from Jool at one of the ideal launch windows, you should arrive at Kerbin with a hyperbolic excess velocity of about 2800 m/s.  I didn't simulate that scenario exactly, but I did run some simulations for V∞ = 3000 m/s.  I used three different ballistic coefficients:  2000, 4000 and 6000 kg/m2 (measured at Mach 10).  I determined a periapsis range of 27-29 km for BC = 2000, 23-25 km for BC = 4000, and 21-23 km for BC = 6000.  Like I said, these numbers were determined by computer simulation, not by in game testing.  I can't guarantee how well it will work in the game.
(edit)  My recollection is that a Mk1-2 command pod has a BC of about 2000 kg/m2 .
 

^ this ^
Make your ejection burn from low Kerbin orbit as you normally would if you were aiming for an equatorial munar orbit.  However, instead of aiming for a close encounter just above Mun's surface as you would if you were planning an equatorial orbit, I like to aim for an approximate dead center impact with Mun.  Then, when about half way to Mun, make a normal/anti-normal burn to alter the trajectory so that you will pass just over one of Mun's poles.  Perform your orbit insertion burn at Pe just as you would in any other circumstance.

The amount of ablator that a heat shield has can be adjusted.  When you first install a heat shield, it defaults to the maximum amount - 200 kg for a 1.25m heat shield, 800 kg for a 2.5m heat shield, and 1800 kg for a 3.75m heat shield.  When you are in the VAB, you can right-click on the heat shield and there is a slider that allows you to reduce the ablator mass.  For returns from Mun and Minmus, you typically don't need the maximum amount.  What I usually do is install the heat shield on the part that will reenter, and turn the slider all the way down to zero.  I then note the mass and take 5% of that amount.  I then increase the slider until the ablator mass is equal to or just over the 5% amount.  I found that I've never needed more than that when reentering from anywhere at or inside Minmus' orbit.  However, for high-speed interplanetary trajectories, you'll likely need a lot more.
 

Assuming your periapsis is the orbit of Kerbin, then
For a 2:1 resonance, Ap = 29,315,361,202 m
For a 3:1 resonance, Ap = 42,716,175,169 m
For a 4:1 resonance, Ap = 54,677,459,799 m
These numbers are altitudes, not radii.  It should be the number you read when hovering your mouse pointer over the Ap.
Rather than worrying too much abut getting Pe and Ap just right, it might be easier to go by semimajor axis.  If your semimajor axis is correct, you should come back to the same spot regardless of whether your Pe and Ap are just right.  Here is what the semimajor axis should be:
For a 2:1 resonance, a = 21,588,400,729 m
For a 3:1 resonance, a = 28,288,807,713 m
For a 4:1 resonance, a = 34,269,450,027 m

Overheating on Duna is not a problem.  I'd recommend a heat shield to play it safe but, for a typical aerocapture, you won't burn off much ablator.  Entry from orbit doesn't need a heat shield at all.  I have found that the aerocapture periapsis is pretty sensitive your entry velocity and the ballistic coefficient of your vehicle.  If you have a relatively slow intercept with a low ballistic coefficient, you'll probably need a periapsis of about 20 km.  If you have a fast intercept with a high ballistic coefficient, you'll probably need a periapsis of about 10 km.  If you miss on the periapsis, you may not aerocapture at all or you may not pull out of the atmosphere.  I'd recommend at practice run and be prepared to revert/reload if you get it wrong.
 

You're correct, the info panel gives the physical characteristics of the body but no orbital information.  However, it does give the gravitational parameter (GM) of each body.
Although there are some mods that will give semimajor axis from inside the game, I don't know if there is a way to do this in the stock game.  However, I'm sure the numbers in the Wiki are correct because I've checked them.
(edit)
One mod that gives the orbital elements is Hyperedit.
If you want a mathematical way to compute semimajor axis from information given in the game, just click on a planet and note its velocity and altitude.  You can then use the Vis Viva equation to compute the value of a, though the precision of this method is limited by the precision of the input variables.
 

As to the why, perhaps the following image will help to illustrate it.


This is just a graph that I made using Excel, so I couldn't get real fancy with labels, etc. Imagine that the planet Kerbin is centered on the origin of the axes (0, 0) with a radius of 600 km. The colored curved lines represent the trajectories that the spacecraft will follow as it leaves low Kerbin orbit and heads out into space. The dashed green line represents the theoretical orbit that the spacecraft would follow if the dV were applied instantly at the maneuver node. The maneuver node is located at the coordinates 0, -680. The red line represents the trajectory we follow by burning prograde. The blue line represents the trajectory we follow by burning to the maneuver node or, more correctly, to the right as the image is oriented. Both the red and blue trajectories start 30 degrees before reaching the maneuver node, with the burn time centered on the maneuver node.

Not only do we want to exit Kerbin space with the correct velocity, but also in the correct direction. The correct direction is along the path of the dashed green line. You can see that when we burn prograde, we immediately start to push the vehicle farther and farther away from Kerbin, ending in a significant deviation from where we want to go. When burning in the direction of the maneuver node, we stay much truer to the desired trajectory. In fact, it looks to me like the location of the maneuver node on the Navball auto-corrects as the burn progresses, which likely keeps us even closer on course than this image represents.

Of course, either trajectory can be made to approximately match the green line by adjusting the start time of the burn. In the case of the blue line, starting the burn a little sooner would move the outgoing path a little closer to the green line (this is what Yasmy suggests). In the case of the red line, we would want to start the burn later, though I'm not sure there's a simple formula to compute the start time.

Since the dV loss that comes with burning to the maneuver node is relatively small, there seems to be little advantage to using the prograde method. Burning to the maneuver node appears to be the easier and better solution.