User accounts on unix-like systems are identified by a UID (user ID).
A process can be associated with more than one UID. The two main ones are the "real UID" which identifies who owns the process and the "effective user UID" which identifies what user's permissions the process currently operates under*.
"setuid" in this context refers to a file permission bit (it is also the name of a related system call). When it is set on an executable file and that file is executed then the "effective UID" is changed to the owner of the file. This means that the program runs with the permissions of it's owner rather than the permissions of the user that ran it.
When we say an executable file "is setuid root" then we mean it has the setuid bit set and is owned by the user 0 (root). So it will run with an effective UID of 0 and can basically do whatever it wants.
The "real UID" remains the same, so the program can identify the user that ran it and can switch back to that user if desired.
setuid programs are/were an important part of unix systems allowing functionality to be exposed to users where the function as a whole is considered safe for the user to use but the building blocks used to implement those functions are not.
However they are also risky, a small mistake in a setuid program can easily expose more than was meant to be exposed. Various debugging related features are also disabled for setuid programs to prevent them being used to bypass the restrictions.
In recent times Linux systems have been replacing some uses of "setuid" with a new mechanism called "capabilities" which allows for finer-grained allocation of special privileges to programs.
* There are potenially others too, but they aren't immediately relavent here, see http://man7.org/linux/man-pages/man7/credentials.7.html for more details.