Add hardware flow support.
Use new struct serial_ringbuffer.

Pass USB CV test verification;
Code cleanup;

This reverts commit 07bd09fc.
The validation of the context is done with in `rt_set_errno`. So it's
safe to call it here.

The errno is associated with threads. It will crash the thread if we set
it in interrupt context.

Return early if the size is 0 as there is nothing to do.

*buffer) with buffer pointer

When forwarding rx/tx callback from the underlaying device(pipe), the
"dev" argument should be the portal. So the portal callback could think
itself as called.

It does not make sense to open portal without a flag. One should open a
portal with RT_DEVICE_OFLAG_RDWR in most cases.

Portal is a device that connect devices. Currently, you can only connect
pipes in portal. Pipes are unidirectional. But with portal, you can
construct a bidirectional device with two pipes.

Pipe have many differences with char device. The main difference is
altough pipe have both read and write, it is unidirectional in nature.

Some reader(FinSh again) would like to block on a semaphore which is
released in rx_indicate. So we should invoke rx_indicate in
_rt_pipe_resume_reader.

The previous implementation will always blocks the reader/writer.
However, at least FinSh would expect the device to be nonblocking ---
read should return 0 when there is no data in it.

Add the APIs that will discard the old data when rb is full.

RT_RINGBUFFER_SIZE could mean "the size of the whole buffer", "the size
of the empty space" or "the size of the data". Moreover, it's never a
micro anymore. Change it to rt_ringbuffer_data_len before it's too late.
Also, RT_RINGBUFFER_EMPTY is changed to rt_ringbuffer_space_len.

This provide the possibility that allocate the buffer of the ringbuffer
on a specific region, instead of always mallocing it. It also bring us
the benefit of using pipe device on the systems without heap.

Some driver will emit USB_MSG_DATA_NOTIFY before the USB get configured.
Filter out those events.

When the core received an USB_MSG_PLUG_OUT event, it will stop all the
classes. This make a chance that the classes could get rid off doing
useless stuff while the USB cable is plugged out.

When the USB got RESET packet from the host and the address is setup,
all the classes will got reset. The reset is done by class stop and than
class run. So the classes should reset their internal state in
class_{run,stop}.

Besides, the USB device driver could post a USB_MSG_RESET message on
every RESET packet.

Reset the vcom state in class_{run,stop} and when the PC is not
receiving data from me.

Although currently the only message send to the queue is struct
udev_msg, in order to keep backward compacity and for extention in the
future, we set the size of message to 32.