A "bare metal" operating system doesn't run within anything. It runs the full instruction set on the physical machine, and has access to all of physical memory, all device registers and all privileged instructions, including those that control the virtual memory support hardware.
(If the operating system is running on a virtual machine, it may think it is in the same situation as above. The difference is that certain things are emulated or in some other way handled by the hypervisor; i.e. the level that runs the virtual machines.)
Anyway, while the OS might be implemented in (for example) C, it won't have all of the normal C libraries available to it. In particular, it won't have the normal 'stdio' libraries. Rather, it will implement (for example) a disk device driver that allows it to read and write disk blocks. It will implement a file system on top of the disk block layer, and on top of that it will implement the system calls that a user application's runtime libraries make to (for example) create, read and write files ... and so on.
How can an application run without being in an OS?
It needs to be a special kind of application (e.g. an operating system) that knows how to interact directly with the I/O hardware, etc.
How do you tell the computer to run, say, C, and execute these commands to the screen, if it doesn't have an OS to run in?
The application (which was for the sake of argument written in C) is compiled and linked on some other machine to give a native code image. Then the image is written to the hard drive in a place that the BIOS can find it. The BIOS loads the image into memory, and executes an instruction to jump to the application's entry point.
There (typically) isn't any "running C and executing commands" in the application unless it is a full-blown operating system. And in that case, it is the operating system's responsibility to implement all of the required infrastructure to make it happen. No magic. Just lots of code.
Bill's answer covers bootstrapping which is the process in which you go from a powered-off machine to a machine in which the normal operating system is up and running. However, it is worth noting that when the BIOS completes its tasks, it (typically) gives over complete control of the hardware to the main operating system, and plays no further part — until the next system restart. The main OS is certainly not running "within" the BIOS in the conventional sense.
Does it have to do with a UNIX kernel? If so, what is a unix kernel, or a kernel in general?
Yes it does.
The UNIX kernel is the core of the UNIX operating system. It is the part of UNIX that does all of the "bare metal" stuff described above.
The idea of a "kernel" is that you try to separate the system software into core stuff (that requires physical device access, all of memory, etc), and non-core stuff. The kernel consists of the core stuff.
In reality, the distinction between kernel/core and non-kernel/non-core is more complicated than that. And there has been a lot of debate over what really belongs in a kernel, and what doesn't. (Look up micro-kernel for example.)