#9478 follow-up: BPS tree interface simplification

[mkostoevr]

The current BPS tree implementation has a huge code duplication and a bloated interface with different functions performing almost identical but slightly different tasks. For example bps_tree_insert and bps_tree_insert_get_iterator, or bps_tree_delete and bps_tree_delete_value.

The problem gets worse after #9478 so it's decided to perform a major tree refactoring in the future to simplify its interface and decrease the code duplication.

[mkostoevr]

One could do #10045 by the way.

Also here's a bunch of NITs:

• the tree has inconsistent comment styles;
• some comments have typos:
  • "down to to search";
  • "untoched";
  • "happend";
  • "@breif"
  • "@brieaf"
• some comments are misleading:
  • bps_tree_root
  • bps_tree_touch_block;
  • struct bps_inner after bps: add support for logarithmic offset #9478;
  • bps_tree_lower_bound_elem_get_offset_impl
  • bps_tree_insert_and_move_elems_to_left_leaf
  • bps_tree_insert_and_move_elems_to_left_inner
  • bps_tree_print
  • information about untouched *offset in [upper|lower]_bound[_elem]_get_offset family of functions.
• compile-time assertions for global and function scope can be merged;
• some places are incompatible with checkpatch checks;
• over 80-character lines:
  • bps_tree_iterator_next(const struct bps_tree *tree, struct bps_tree_iterator *itr);
  • bps_tree_iterator_prev(const struct bps_tree *tree, struct bps_tree_iterator *itr);
• miscellaneous:
  • #define bps_tree_touch_path _bps_tree(touch_path_max_elem)
  • unused macro _bps_tree_name
  • BPS_TREE_BRANCH_TRACE could be a oneliner
  • bps_tree_build::sorted_array could be a pointer to const
  • this could fit in one line: matras_create(&t->matras,