Replace the ACL library with the BPF library

When a NIC doesn't support filters that a functional block needs, the block falls back to register the needed filters through an internal API that essentially uses ACL to do the matching. However, the ACL library doesn't account for variable-length headers such as Ethernet, IP, and TCP. Thus, the internal API requires blocks to register ACL filters and a function to deal with variable headers. This solution duplicates tests and complicates the code of the blocks.

A solution is for the internal filter API to receive the needed filters and classify the packets with the help of a BPF program created on the fly. For example, IPv4 filters would be the following tuples (destination IP address, next protocol, source port number, destination port number). Each field of this tuple should be optional. This internal filter API would organize all the registered tuples in a binary tree as follows:
1. Each node of the binary tree is a tuple with the information of the values of the fields;
2. The right edge of a node is reserved for nodes that do not match the current node up to the current level of the node. The level of the root of the binary tree is zero, and it increases by one when a left edge is followed. This way, at level zero, following only right edges would list all tuples that have different destination IP addresses.
3. When the fields of some tuples share the same values up to the level they are, one tuple stays at the current level, the second tuple is linked at the left edge of the tuple that is kept at the current level, and all other tuples are listed at the right edge of the second tuple.
4. The filter API should only accept unique tuples, so there's never ambiguity in how packets are classified.

The construction above allows one to navigate the binary tree and easily generate BPF bytecode to classify packets: following right edges lead to sequences of `if` statements, while following left edges lead to what goes inside of the previous `if` statements. Optional fields can be easily dealt with by placing the corresponding tuples at the end of the list of right edges of a given level.

The problem of variable headers can be solved by making the running environment of the generated BPF program similar to the environment used for BPF programs used to enforce policy decisions: it includes the sizes of the headers of the packets. The sizes of the headers are already available when the filter API receives the packets for classification.

In order to support different node types to support IPv4 and IPv6 with the same code of the library, the library must support the nodes being defined with functions like `bool is_field_option(int field_number)`. The API may even generate a single BPF program to classify IPv4 and IPv6 packets all at once if this is convenient by combining the output of IPv4 and IPv6 tuples. Another approach is to identify the fields of the nodes as the tuple (header level, field bit offset, field bit length, field bit mask in network order, field value in network order). For IPv4, the following tuple tests the version of the header (L3, 0, 4, 0xF, 4).

Given that the proposed solution would have a broad impact on the code and may interact with DPDK's Generic flow API (rte_flow), this issue should only be addressed after issue #294 is closed.

Although the new API itself would have a complicated code, it would simplify the code from the perspective of the blocks, avoid duplicate tests on packets to be classified, and likely be faster overall.