[NB: this answer is specifically intended to address the recent edit and does not otherwise add to the several sound answers that have already been posted.]
So, to reiterate: microcode (at least to a first approximation) is a specific kind of firmware.
"Microcode" is in this context is just marketing over "processor firmware."
Well, it's not marketing. Marketing would have called it XBoost Pro(TM) or something. Rather, it's an engineering term; if you design CPUs, the distinction between microcode and the CPU's other firmware (and the sort of firmware typical to other devices) is important to you. If not, it probably isn't.
If you design motherboards or write operating systems, you probably use "microcode update" as shorthand for the more unwieldy and less familiar "CPU firmware update". Most CPU firmware updates primarily affect the microcode, so it's close enough to the same thing. You probably do know the difference, but you don't need to care about it.
The end user doesn't need to know or care about the difference, and in an ideal world would never hear the word "microcode" at all.
I'm guessing it came to your attention in press coverage of the recent speculative execution vulnerabilities, though you might also have heard it earlier in a context that made it more obvious that you didn't need to care. These vulnerabilities were released earlier than planned which may have resulted in press coverage being less curated than it might otherwise have been. From the end user's point of view, you need to install BIOS updates, operating system updates, and in some cases application updates; you need neither know nor care which if any of these include new microcode.
So, even realizing that you probably don't need to know or care, you may still be interested out of pure curiosity: how might you go about distinguish microcode from other firmware?
Well, the first thing to recognize is that there isn't necessarily a single hard and fast definition, it is more of a Bleggs and Rubes situation. Still, there are some things we can say about microcode:
Microcode generally runs inside a CPU rather than on a CPU. That's the high-level view.
The architecture of microcode typically looks quite different to the architecture of ordinary code, including ordinary firmware. It is likely to be highly parallel, and be implemented much closer to the hardware. Several of the existing answers (including your own answer) discuss this, though it should be noted that the details may vary depending on the CPU design.
Although hardware is often designed to run only the firmware provided by the manufacturer, it is not particularly uncommon for third-party firmware to be used - though it will probably invalidate the warranty! Third-party microcode is much much rarer, though I believe that in ancient times (I'm talking about when a CPU was about the size of a breadbox) some end-users would modify the microcode in their CPUs. So far as I'm aware, this isn't possible in the sort of CPUs used in PCs.
Microcode typically translates or helps to implement a public instruction set architecture, i.e., it runs the machine code that the operating system designer and application programmers use. More on this in the next section.
"Execution vs data" a lot of answers use this paradigm
In confusingly different ways, I fear, but I'll address my own comment. This section also serves to expand on the last bullet point above. The goal here is to try to distinguish between the job that a CPU is doing (achieved by a combination of hardware and microcode) and the job that a typical device is doing (achieved by a combination of hardware and firmware). I'm going to choose a SATA hard disk drive.
The SATA drive follows instructions from the computer, which are along the lines of "read the data from sector 5,123" and "write this data into sector 1,321". The drive's firmware is responsible for making the hardware make this happen, and it is typically pretty ordinary code running on an embedded CPU of some sort. The drive's instructions arrive sequentially, though they might not be processed in the order in which they arrive. These instructions aren't a program, they are sent by a program running on the main CPU. In particular there is no flow of control, i.e., no instruction to tell the SATA drive which instructions to run next.
The CPU is in charge of the computer. Once it has finished initializing it runs the instructions ("machine code") provided by the motherboard (the BIOS, another type of firmware) which direct it to run the machine code provided by the operating system which directs it to run the machine code provided by application vendors. The CPU itself retrieves the machine code from EEPROM (in the case of the BIOS) or RAM (in the case of the operating system and applications). In particular, machine code has a flow of control: the machine code tells the CPU what machine code to perform next. You can loop over the same machine code repeatedly, you can run different bits of code depending on the data the code is working on - the instructions in a device interface language like SATA code can do a limited set of simple tasks, but machine code can do anything. (See also Turing Completeness.)
We could rewrite that final bullet point above as: microcode usually implements a Turing Complete language; ordinary firmware usually doesn't.
What does it mean to say "hardware instructions are interpreted" with microcode.
True but probably confusing; the important point is the distinction between machine code, which has a flow of control and is Turing Complete, and the instructions defined by a device interface such as SATA, which doesn't and isn't.
Does "microcode" apply to the code that runs on sound cards
No, sound cards receive instructions, not code, just like SATA drives. The instructions might be like "play A sharp" or "interpret this data as a waveform and play it". Still very simple.
and video cards (GPUs)?
Old fashioned video cards (those without GPUs) are the same as SATA drives. The instructions are like "set this pixel to this colour" or "write an A to this position".
... GPUs are complicated and sit somewhere between the two worlds I've attempted to describe above. It is probably simplest to think of them as an specialized computer sitting inside the main computer, one which has its own CPUs. It's true that devices like SATA drives also have embedded CPUs, but the difference is that the embedded CPU in a SATA drive only runs code provided by the drive manufacturer, whereas GPUs also run code provided by the operating system and/or application vendor. Really this is a whole separate question.
TL;DR: microcode is a specific kind of firmware, which helps the hardware to implement a Turing Complete instruction set.
