Let users supply their own statically linked code signature files

Related to #220. Solve this only after #220.

Related to #221, #222, #223, #224, #225. Solve them together or close one after another. Share design decisions - uniform solutions.

Let users supply their own statically linked code signature files. This is partially solved. See #143 and [wiki page](https://github.com/avast-tl/retdec/wiki/Removing-Statically-Linked-Code).

Probably refactor the whole system in the process:
- Refactor the directory structure. Something like `share/retdec/support/static-code/`.
- Currently, there is a tree directory structure in `share/retdec/support/generic/yara_patterns/static-code`. Flatten it to one level. Rename files so that metadata are in their names. We need this to decide which patterns to use for the currently decompiled file without parsing the files (if metadata were inside files). Metadata: architecture (including bit size), endian, file format, compiler, compiler version, debug (windows), language. E.g. `arm32-little-elf-gcc-4.9-_-c.yara`. If some field is not set `_` is used (e.g. debug in this case). RetDec then parses this metadata and uses it to decide whether to use this pattern file. Set fields must match the analyzed file, unset fields are not checked. For example, `arm32-little-elf-gcc-4.9-_-c.yara` would be used only for 32-bit little endian arm elf files generated with gcc-4.9 from C/C++ sources. `arm32-little-elf-_-_-_-_.yara` would be used for all 32-bit little endian ARMs.
- Think about more elegant implementation of this mechanism.
- Let users specify their own pattern file(s) or whole directory(s) through retdec-decompiler.sh script parameter. Specified files can be both YARA patterns and archives. This is already implemented (see [wiki page](https://github.com/avast-tl/retdec/wiki/Removing-Statically-Linked-Code)).
- Let users add their files to the user support directory (e.g. something like `share/retdec/user-support/static-code/`). These will be always used, without user needing to specify them via script parameters. Allow only YARA files here, not archives. File names must/may (?) be in the format described above, so that it is possible to automatically decide if they should be applied. If this format is not enforced, unrecognized files will be always applied (potentially undesirable). If it is, it is still possible to create files where all the metadata are unknown - always applied. However, I would think that it is always possible to define at least architecture. Probably add another metadata type - name. It will be used to distinguish files, since less metadata is specified, greater the chance for name collision.
- Modify existing script for signature creation to allow users to specify metadata via command line arguments. Use them to generate files with recognizable names. Therefore, user would specify archives he wants to use, their common properties (metadata), and script would generate pattern files that user could copy to user support directory and automatically use. User could potentially bundle all kind of archives together (e.g. arm32 and mips64) and not set any common metadata. Discourage this on wiki, since it is not a good idea, but ultimately, it is users decision.
- Write, in this case expand, a how-to wiki page.

Start with #220 and the existing implementation described in #143 and the linked wiki page. Inspect share/retdec/support/generic/yara_patterns/static-code, retdec-decompiler.sh, and the existing signature-creation script. Done means users can supply files or directories, user-support patterns are selected by metadata, generated names are recognizable, and the wiki contains the expanded how-to.

Written by the indexing model from the issue text.