libsmack: reorganize rule lists for struct smack_accesses

Until now rule list was implemented as single linked list of all rules
added into struct smack_accesses. This patch breaks this list into several
lists, with one list of rules per subject label.
Label dictionary (added in cd2ce11) is now merged with smack_accesses (it's
abstraction layer is dropped). Each element in array of labels describe
single label and all rules when it's a subject are added into this label's
list.

This data structure is close to internal kernel data structures for Smack
rules. This allows for slightly better performance because rules are
grouped by subject.
More importantly though, this patch prepares ground for rule merging.

Signed-off-by: Rafal Krypa <r.krypa@samsung.com>
libsmack: merge rules with the same subject and object before applying them

All rules with the same subject and object will be merged into a single one
before applying rules to kernel or writing them to a file. The result will
consist of smaller number of rules, but they will have the same semantics.
This enhances performance greatly when there are a lot of rules to merge.
The merging code has negligible overhead when there are no merges to
perform.

Signed-off-by: Rafal Krypa <r.krypa@samsung.com>
libsmack: implement internal hash table of labels

Use hash table implemented internally for dictionary of labels.

Thanks to that some operations are more efficient:
-it is possible to use better hashing function than in hsearch:
 DJB2 algorithm is used, which is much better, than hashing function
 used in hsearch. Hashing function in hsearch causes, that on 32bit
 machines, all labels that have common first eight bytes,
 share same bucket and this cause many conflicts in combination of labels
 naming convention with domain-based prefixes. This leads to significant
 performance degradation in real system. This was not detected on tests
 so far, because labels for test policies were generated randomly.
-it is possible to calculate hash during label validation.
-it would not cause drastic complexity growth to have number of labels
 near to number of allocated buckets as it happens in hsearch.
-it would be possible to add number of labels exceeding number of
 allocated buckets.

Signed-off-by: Jan Cybulski <j.cybulski@samsung.com>
libsmack: add possibility of resizing table of labels

Signed-off-by: Jan Cybulski <j.cybulski@samsung.com>