The `Rules.match` function now receives an optional `allow_duplicate_metadata=True` argument, which changes the structure of `Match.meta`. By default `Match.meta` is a dictionary with metadata names and their corresponding values, if a metadata name appears duplicated in a rule, the last value will be used. For example, consider the following rule:

```yara
rule demo {
   meta: 
     foo = "foo #1"
     foo = "foo #2"
     bar = "bar"
   condition:
      false
}
```

In that case `Match.meta` would be `{"foo": "foo #2", "bar": "bar"}` by default (`allow_duplicate_metadata=False`), but with `allow_duplicate_metadata=True` it would be: `{"foo": ["foo #1", "foo #2"], "bar": ["bar"]}`. 

When compiling rules that have warnings currently the only way to know they have
warnings is to specify error_on_warning=True to yara.compile(). This will throw
an exception that you can then check the warnings member of, like this:

```
r = 'rule a { strings: $a = "a" condition: $a } rule b { strings: $b = "b" condition: $b }'

try:
    rules = yara.compile(source=r, error_on_warning=True)
except yara.WarningError as e:
    print(e.warnings)
```

This stops the compilation process, so if you're trying to just know if there
are warnings but still run the rules there is no good way to do it without using
the exception mechanism and then compiling the rules a second time (with
error_on_warning not set).

This patch adds a warnings member to the compiled Rules object, which is always
set to a list of warning strings. If you want to error on warning you can still
use error_on_warning=True in yara.compile() and get the normal behavior, but if
you just want to compile and know if there are warnings you can now use this new
member without having to compile a second time.

Suggested by: Tom Lancaster
Fixes: #207

* Add console_callback to match call.

This provides the user with an interface to handle console.log() messages. If
not provided the log message is printed to stdout (limited to 1000 bytes based
upon https://docs.python.org/3/c-api/sys.html?highlight=stdout#c.PySys_WriteStdout).

Tested with the following (along with the updated tests):

wxs@wxs-mbp yara-python % cat test.py
import yara

r = """
import "console"

rule a { condition: console.log("Hello from Python!") }
"""

def console(message):
    print(f"Callback: {message}")

rules = yara.compile(source=r)
rules.match("/bin/ls", console_callback=console)
rules.match("/bin/ls")
wxs@wxs-mbp yara-python % PYTHONPATH=build/lib.macosx-10.14-arm64-3.8 python3 test.py
Callback: Hello from Python!
Hello from Python!
wxs@wxs-mbp yara-python %

* Add comment.

Closes #193

* Build for Python 3.10

* Update build command

bdist_wininst was deprecated in python 3.8 (and removed in python 3.10) and bdist_msi was deprecated in python3.9

rules.Match currently has an innate race condition when using
external variables. To avoid this, use a YR_SCANNER.

Removing Travis

Seems APPVEYOR_REPO_COMMIT is not getting the commit ID properly, let's try with the branch name (it should be updated at this point)

* Release GIL when compiling rules.

The compilation is a blocking operation and can be potentially CPU
intensive. There is no reason to hold GIL.

* Lock the GIL in callback to prevent segmentation fault.

To be uniform with other callbacks and to prevent the SIGSEGV we have to
lock the GIL while we want to interact with python objects. The callback
is called from a C code releases GIL. Other callback functions use the same
locking strategy.

namespace identifier to the callback

Because the function was initializing pid as 0, when the user passed pid=0 as an argument it was indistinguishable from not pid being passed at all.

Closes https://github.com/VirusTotal/yara/issues/1480

The previous commit was still wrong.

As pointed out by Arnim Rupp (@2d4d) in #172, the fix in #175 was not complete as there's was no performance gain when the callback was not provided, which is the most common case.

This function has grown too much, so it was split in multiple functions in order to make it easier to understand.

Now the rule identifier is printed as part of the warning message, the string identifier is not descriptive enough in many cases.

* When building on macos I noticed that libcrypto was not found when using
has_function(). This is because the compiler used to compile the check program
is not being told about the library and include paths. Fix it by passing those
into the has_function() check where appropriate.

* Improve callback performance for non-matching case.

Add support for a "warnings_callback" argument to Rules.match(). If provided the
function definition needs to be:

def warnings_callback(warning_type, message)

The callback will be called with a warning type of yara.WARNING_TOO_MANY_MATCHES
and the message will be a string indicating which rule caused the warning. I
think a warning type and a message is reasonably flexible in case we introduce
other runtime warnings in the future.

If a callback is not provided we print a warning on stderr using the normal
python warning system. It's worth noting the function I'm using was introduced
in python 3.2. I can switch it to something more portable if you don't want to
pull support for 2.x yet.

While I'm here, also chase the renaming of rules_list_head and other list
variables so that it can compile with latest yara master.

When compiling YARA without Python bindings, stdbool.h is actually used
if it can be used. However Python bindings completely ignore it resulting
in YARA defining its own bool type with sizeof(bool) == sizeof(int).
However before [#1377](https://github.com/VirusTotal/yara/pull/1377), this
can result in different compilation units using different sizes of
bool type and chaos ensues.