util: Add ALIGN_POWER2

Add static inline function to align a value to it's next power of 2.
This is commonly done by a SWAR like the one in:

http://aggregate.org/MAGIC/#Next Largest Power of 2

However a microbench shows that the implementation herer is a faster.
It doesn't really impact the possible user of this function, but it's
interesting nonetheless.

Using a x86_64 i7 Ivy Bridge it shows a ~4% advantage by using clz
instead instead of the OR and SHL chain. And this is by using a BSR
since Ivy Bridge doesn't have LZCNT. New Haswell processors have the
LZCNT instruction which can make this even better. ARM also has a CLZ
instruction so it should be better, too.

Code used to test:

	...
	v = val[i];
	t1 = get_cycles(0);
	a = ALIGN_POWER2(v);
	t1 = get_cycles(t1);

	t2 = get_cycles(0);
	v = nlpo2(v);
	t2 = get_cycles(t2);

	printf("%u\t%llu\t%llu\t%d\n", v, t1, t2, v == a);
	...

In which val is an array of 20 random unsigned int, nlop2 is the SWAR
implementation and get_cycles uses RDTSC to measure the performance.

Averages:
	ALIGN_POWER2: 	30 cycles
	nlop2:		31.4 cycles
libkmod-hash: always align n_buckets to power of 2

By aligning n_buckets to power of 2 we can turn the "bucket = hashval %
n_buckets" into a less expensive bucket = hashval & (n_buckets - 1).
This removes the DIV instruction as shown below.

Before:
	xor    %edx,%edx
	divl   0x8(%rbx)
	mov    %edx,%eax
	add    $0x1,%rax
	shl    $0x4,%rax
	add    %rbx,%rax

After:
	lea    -0x1(%rdi),%edx
	and    %edx,%eax
	add    $0x1,%rax
	shl    $0x4,%rax
	add    %rbx,%rax

With a microbenchmark, measuring the time to locate the bucket (i.e.
time_to_calculate_hashval + time_to_calculate_bucket_position) we have
the results below (time in clock cycles):

	keylen      before   after
	2-10          79.0    61.9 (-21.65%)
	11-17         81.0    64.4 (-20.48%)
	18-25         90.0    73.2 (-18.69%)
	26-32        104.7    87.0 (-16.82%)
	33-40        108.4    89.6 (-17.37%)
	41-48        111.2    91.9 (-17.38%)
	49-55        120.1   102.1 (-15.04%)
	56-63        134.4   115.7 (-13.91%)

As expected the gain is constant, regardless of the key length.
The time to clculate the hashval varies with the key length, which
explains the bigger gains for short keys.