This patch continues the refactoring of Tarantool package.loaders
required for Tarantool integrity protection.

Originally, Lua uses only constant path patterns in package.path and
package.cpath. Tarantool enhances the user experience here and provides
more relaxed rules for module searching: some paths are calculated at
the moment the module is being searched and are relative to the current
working directory. Unfortunately, it makes "searchers" more complex,
since all the paths can't be calculated when Tarantool starts up.

Furthermore, there is the particular priority while loading Lua modules
in Tarantool. Originally, Lua tries to load the particular Lua script
using the hints from package.path and *only if* no Lua module is found,
Lua tries to load the corresponding Lua C library using the hints from
package.cpath. Tarantool loaders are prioritized by the locations at
first and only then by the module implementation. This also makes
"searchers" structure more complex than it could be.

Anyway, "file" loaders are split into the three layers:
1. "Pathogen": the function generated by <gen_path_builder>, building
   the hints for searchers
2. "Searcher": the function generated by <gen_file_searcher> helper,
   using the particular file loading method (<load_lua> or <load_lib>)
   and the given pathogen to obtain the hints with path patterns to be
   used in <package.searchpath> routine
3. "Loader": the function generated by <gen_file_loader> helper,
   following Lua 5.1 loaders semantics and using the particular searcher

All the generated searchers are stored in the <package.searchers>
analogue introduced in the first patch of this refactoring series.

It's worth saying that "app" paths injection is still implemented via
chained loaders, but this machinery will be reimplemented within the
following patches in this series.

Needed for tarantool/tarantool-ee#585

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring