rt_event_recv: add a check on the option flag

Simulator

Either RT_EVENT_FLAG_AND or RT_EVENT_FLAG_OR should be set in the option
flag. If none of them is present, the waiting thread will never be
resumed.

This gives ways for bsp to set it's own RTT_CC.

Building is only the first step. Correctness is what we need. There are
already many GCC builds for other bsp so GCC building for simulator is
not important. So I use clang-analyze to check all the source codes in
simulator project. Hope it will help us.

When CROSS_TOOL or 'RTT_CC' env is setted to 'clang-analyze', it will
use Clang to check the codes.

Bsps can use the clang analyzer as a tool:

    env = Environment(toolpath=[os.path.join(RTT_ROOT, 'tools',
                      'tools')], tools = ['clang-analyze'])

When building the project, the static analyzer will be called to check
all the C code. The warnings are print to stderr.

The `clang -fsyntax-only` will give us additional warning messages in
the console.

Simulator get it's way to Travis CI ready.

This could not only make a cleaner SConstruct, but could also benefit
RTGUI building.

sim/posix: move rt_hw_context_switch_interrupt after it's definition

This fix a compile error in Clang.

stm32f10x: fix the rtgui initialization

The rtgui_system_server_init prototype is wrong. And if we use
RT_USING_COMPONENTS_INIT, there is no need to call
rtgui_system_server_init again.

log_trace: cleanup

finsh: use alias in the variable definition

Simulator linux

With this patch, one could define two alias for the same function like:

    FINSH_FUNCTION_EXPORT_ALIAS(rt_hw_cpu_reset, reboot, reboot the cpu);
    FINSH_FUNCTION_EXPORT_ALIAS(rt_hw_cpu_reset, __cmd_reboot, reboot the cpu);

Suitable for being used in MSH/Finsh.

SDL may use DFS to open files. It should be run after
rt_components_init.

rt_hw_sdl_start should wait untill the rtgui_graphic_set_device is
called int the sdl_loop. Use pthread_cond_wait to achieve this in Linux.

Some fix for the portal device

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.

finsh/cmd: add description for new pipe and portal device

Portal device

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.

Ringbuffer and Pipe