Introduce <<< operator for new aggregation support

This patch introduce new aggregate operator: <<<
For example:
	s = ptable()
	s["test"] <<< 1
	s["test"] <<< 2
	print(s["test"])    ---> [count: 2 sum: 3 max: 2 min: 1 avg: 1]
	print(count(s["test"])		---> 2
	print(sum(s["test"])		---> 3
	print(max(s["test"])		---> 2
	print(min(s["test"])		---> 1
	print(avg(s["test"])		---> 1

This new aggregation mechanism is borrowed from systemtap,
also old ktap aggregation is killed now.

The reason for this change is new aggregation syntax will be more
easily for end user, "<<<" just look like stream operator, similar
with aggregation in some level.

In implementation, count/sum/max/min value stores in structure
ktap_stat_data, this structure is bind with table tightly, it allocate
with table nodes and array, and resize at same time. This will
avoid much ktap_stat_data memory allocation.

old builtin function "aggr_table" is replaced by "ptable",
which respesent parallel table.

The testcase(test/ptable.kp) and sample scripts are also updated.

Signed-off-by: Jovi Zhangwei <jovi.zhangwei@gmail.com>
disable preemption when update ktap_stats

Kernel reported below warning in preempt kernel.

    BUG: using smp_processor_id() in preemptible [00000000] code: ktap/1865
    caller is kp_malloc+0xbd/0xd6 [ktapvm]
    CPU: 11 PID: 1865 Comm: ktap Tainted: G           O 3.12.0-rc6+ #5

The reason is we didn't disable preemption when update
percpu variable ktap_stats, this patch fix it.

Signed-off-by: Jovi Zhangwei <jovi.zhangwei@gmail.com>
rename email name

Use "Jovi Zhangwei" instead of "zhangwei(Jovi)"

Signed-off-by: Jovi Zhangwei <jovi.zhangwei@gmail.com>
remove COPYRIGHT file in top-level directory

copyright notice already moved to each file header.

Signed-off-by: Jovi Zhangwei <jovi.zhangwei@gmail.com>
move test/ansi.kp to scripts/ansi/ansi_color_demo.kp

It looks werid when running ansi.kp(clear screen, show color)
in ktap testsuite, move it to scripts/, to be a sample script.

Signed-off-by: Jovi Zhangwei <jovi.zhangwei@gmail.com>
add locking for percpu table get/set

Even though ptable operate on percpu table mostly,
but this doesn't means we can drop the lock for percpu
table, because there still could have operating on
same table in different threads, for example:

	s = ptable()

	trace probe:schedule {
		s[execname()] <<< 1
	}

	tick-100ms {
		print(s)
	}

To avoid aggregation data corruption, add lock for percpu
table.

Don't need worry about table lock contention in here, because
there don't have lock contention between each tracing thread,
that's the reason why percpu table introduced for aggregation.

Signed-off-by: Jovi Zhangwei <jovi.zhangwei@gmail.com>
use aggregation in scripts/tracepoints/eventcount.kp

Use aggregation table to avoid table lock contention.

Signed-off-by: Jovi Zhangwei <jovi.zhangwei@gmail.com>
dump settable instruction

Signed-off-by: Qingping Hou <qingping.hou@gmail.com>