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.

* Allow a Py_buffer as data for Rules_match

This makes rules matching compatible with data objects
`PyArg_ParseTuple` does not consider read-only (even though they might
actually be), such a memoryviews. The main change is replacing the `s#`
formatter with `s*` and replacing the `(pointer, length)` pair with a
`Py_buffer` object accordingly. Additional care must be taken to release
the `Py_buffer` on every error path.

* Rules_match: zero-initialize data

PyArg_ParseTupleAndKeywords does not initialize optional fields unless
they are passed, which means we need to zero-initialize the data buffer
to be sure the later NULL checks always work.

This commit also gets rid of the unneeded has_data flag.

* Add test for matching on a memoryview

This is regression in introduced in #140. When a string in the metadata section contains invalid UTF-8 characters the behavior Python 2 is leave the string exactly as it appears in YARA, in Python 3 however the invalid characters are removed because Python 3 strings are not handled as bytes like in Python 2, they most have a valid encoding. PR #140 was an attempt to homogenize the behavior in both versions of Python, but it introduced this other issue.

* Support a "is_global" and "is_private" member on Rules.

When writing linters it is currently impossible to know (via rule introspection)
if a given rule is private or global. We have banned global rules for our use
case and we have to resort to a janky regex against our rules files to know if
anyone is about to commit a global rule. I figure exposing these two flags via
python will be useful for programatically checking those bits.

I'm not very pleased with the name "is_global" - I wanted to go with just
"global" and "private" but "global" is a reserved keyword and rule.global breaks
the python interpreter. I'm open to changing the member names if you have any
suggestions.

* Decrement reference counts on global and private.

* Update global and private checks after API changes.