The full Wiki definition applies to operating systems. There are simply too many states for a simple 'project'. Swapping out is an example but it assumes a Memory Management Unit to control what is located where in memory and, in fact, whether the code is even in memory (still or yet).
Your original question was about just 3 process states and that's pretty easy. You could write a serial IO interrupt handler that takes characters from the receiver and stuffs them in a circular queue as a result of an interrupt. It then posts a flag that the queue has data. The scheduler, however it is done, tests the flag and calls the code that processes the queued data. There is no point in calling code just to find out that data isn't available when the interrupt handler can post a flag that there IS data.
The interrupt handler probably exists outside the RTOS span of control (it likely won't be scheduled in any way) and the serial input task waits on a semaphore from the interrupt handler. The scheduler notices the semaphore (flag) and schedules the queue handler. That may, or may not, be the highest priority task. I suppose it could vary as the queue fills up. One char - no hurry, 127 chars filled in a 128 char buffer, better get to it.
Solution 2 deserves a lot of attention because it is a common chunk of code for uCs that don't have a formal OS (like Linux or Windows). You simply wouldn't have the resources in a small uC to implement a complete OS. Nevertheless, the Raspberry PI (among others) does run a complete OS on a high end uC.
Even if an RTOS isn't strictly necessary, it provides a mechanism for segmenting the project. Individual tasks do their own thing without worrying about what some other task is doing. This makes the project easier to create and maintain.