What is non-CDB @ Oracle ?
A non-CDB is anything that isn't a CDB; that is, any database before 12c, or a 12c database created without the enable pluggable database clause. If you create a non-CDB it isn't Multitentant and is a single-instance standalone like a pre-12c database.


  Is non-CDB one single Database process with several databases or Is non-CDB several Database processes?


Neither, it's a single instance (set of processes) with a single database.

The definition you quoted refers to an aspect of non-Mulitenant architecture:


  stacked single-instance databases


So you have one or more Oracle homes (software installations), each with one or more independent databases running from that home. This was the only way to run multiple databases on the same server before 12c's container/pluggable model.

The problem with doing that is the database instances are completely independent and have no visibility of each other, so they are all competing for resources (CPU, memory, network) at operating system level, and you have to have enough resources for them all to be running at peak to avoid degraded performance, even if that is unlikely to happen often. Or don't have enough resources and one or more end up starved at some point. You don't want that happening in production, so it's generally considered a bad idea to do this in production environments.

This is also touched on in the 12c documentation:


  A typical response to the management problem is to place multiple databases on each server. The problem is that the multiple database instances do not share background processes, system and process memory, or Oracle metadata.


12c's Multitenant model gives you a single container database that manages the resources at operating system level and shares them with the pluggable databases as needed, potentially significantly reducing the total resources the O/S server needs, and hiding/simplifying the management of the plugged-in dtabases.

It's somewhat analogous to running virtual machines on a physical server - the physical server needs fewer actual CPUs and less memory than are allocated in total to all the VMs, and the VM management layer controls the balancing and contention of the resources depending on the actual needs and loads of all the VMs. The VMs themselves aren't really aware of that happening, they just use what they need; similarly pluggable databases aren't really aware that the container is managing their resources rather than the operating system.