Why use an Initialization Vector (IV)?
Many cryptographic algorithms are expressed as iterative algorithms. E.g., when encrypting a message with a block cipher in CBC mode, each message "block" is first XORed with the previous encrypted block, and the result of the XOR is then encrypted. The first block has no "previous block" hence we must supply a conventional alternate "zero-th block" which we call "initialization vector". Generally speaking, an IV is whatever piece of data is needed to begin running an algorithm, and is not secret (if it was secret, we would call it a "key", not an IV).
If you take a look at MD5, you see that it is an iterative algorithm which has a "running state" (four 32-bit words) and processes message data by 64-byte chunks, each yielding the next running state; the final state is the hash output. This has to begin with a conventional initial state, which is described in section 3.3 of the RFC.
Since an IV has some cost (e.g. it must be transmitted along a message), it is not there just for aesthetic reasons: algorithms which use an IV need it to fulfil some sort of security property, and this may imply some constraints on what value an IV may have. This really depends on the algorithm. For instance, with MD5, the IV is fixed and this is not an issue. For the case of CBC, see this answer to a previous question. Since uniform randomness is a difficult requirement (alea is a scarce resource, especially in embedded systems), it is considered a good thing if an encryption algorithm requires only a non-repeating IV (e.g. a simple counter); this is all that newer encryption modes such as EAX need.
An IV can be made public but nothing forces you to. It still tends to have a lifecycle distinct from that of a key, in that (for symmetric encryption) you need a new IV per message but not necessarily a new key. For instance, with TLS 1.2, a session key is created during the tunnel setup (the "handshake"), then data is encrypted as so many "records" (up to 16 kB of data per record) and each record has its own IV.
Well, the exact reason for an IV varies a bit between different modes that use IV. At a high level, what the IV does is act as a randomizer, so that each encrypted message appears to be encrypted to a random pattern, even if those messages are similar. In general, IVs disguise when you encrypt the same message twice (and more generally, when two messages you encrypt are related).
To answer your specific questions:
How are IV's used? The are one of the inputs specified to various block cipher modes of operation. Both the encryptor and the decryptor needs a copy of the IV to process a message; this IV need not be secret. Exactly what the mode of operation does with the IV depends on the mode; for CBC mode, CBC mode XOR's each block with the previous ciphertext block; for the first block (where there is no previous one), the IV stands for the previous ciphertext block.
What are the advantages/disadvantages of using an IV? If you are using a mode of operation that uses an IV, using one is mandatory; the question then becomes 'do we send an explicit on, or do we have the encryptor/decryptor agree on how they will compute the IVs'. How the later works depends on what they agree upon, and how well that fulfills the requirements the mode of operations places on IVs. If the question is 'why use a mode of operation that uses an IV', well, using a deterministic encryption method, it becomes impossible to disguise when you encrypt the same message twice. Even if that is not a concern, it also becomes difficult to disguise when you're encrypting related messages (say, messages where the first 16 bytes are exactly the same). This can be solved without an IV; it does involve nonstandard modes.
Why use an IV instead of a longer key in which some section of the key is public? Because the IV needs to change for every message.
What happens to various security properties if an IV is insufficiently random? That really depends on the mode of operation. On one extreme, we have GCM and CTR mode, which couldn't care less if the IV is perfectly predictable (on the other hand, the security properties fail if you use the same IV for two different messages; hence we often use a counter to generate GCM and CTR IVs). On the other extreme, we have CBC, where predictable IVs is known to allow a decryptor to recover plaintext with some work (and this is not a merely theoretical weakness, someone has recently announced a tool that uses this weakness to recover PayPal authentication cookies in TLS 1.0).
Are IV's always public knowledge? Well, they don't have to be public knowledge. However, they can be, and because the easiest way to transport them from encryptor to decryptor is just include them in the ciphertext, they usually are.
Given that IV are often public, are there any attacks that involve a man-in-the-middle attack that alters the IV? Well, I would hope that any encryption mechanism would also include an integrity check which should catch this. If this check is on the plaintext, any change in the IV will also modify the plaintext, and so it will check this. If this check is on the ciphertext, the check will need to include a check on the IV.
