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

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"]}`.

* chore(update): Update documentation URL

- Update documentation URL
- Update copyright year

* chore(update): Change copyright year

* chore(update): Change copyright year

* fix: README.md doesn't exist

* Support xor_value in returned strings.

Extend the tuple that represents an instance of a match to include the xor key.
This breaks all existing scripts that are unpacking the tuple, which I'm not
very happy with.

This also updates the submodule to use the latest master so that I can get the
new xor key values.

Also, adds a fix to get yara building here by defining BUCKETS_128 and
CHECKSUM_1B as needed by the new tlsh stuff (discussed with @metthal).

* Add two new objects to yara-python.

Add a StringMatch object, which represents a matched string. It has an
identifier member (this is the string identifier, eg: $a) and an instances
member which contains a list of matched string instances.

It also keeps track of the string flags internally but does not expose them
directly as the string flags contain things that are internal to YARA (eg:
STRING_FLAGS_FITS_IN_ATOM). The reason it keeps track of the string modifiers
is so that it can be extended to allow users to take action based upon certain
flags. For example, there is a "is_xor()" member on StringMatch which will
return True if the string is using the xor modifier. This way users can call
another method (discussed below) to get the plaintext string back.

Add a StringMatchInstance object which represents an instance of a matched
string. It contains the offset, matched data and the xor key used to match the
string (this is ALWAYS set, even to 0 if the string is not an xor string).

There is a "plaintext()" method on the StringMatchInstance objects which will
return a new bytes object with the xor key applied. This allows users to do
something like this:

```
print(instance.plaintext() if string.is_xor() else instance.matched_data)
```

Technically, the plaintext() method will return the matched_data if the xor_key
is 0 so they don't need to do the conditional but this allows them a nice way to
know if the xor_key is worth recording along with the plaintext.

I decided not to implement richcompare for these new objects as it isn't
entirely clear what I would want to do the comparison on.

* Add "matched_length" member.

Add a "matched_length" member to match instances. This is useful when the
"matched_data" member is a subset of the actually matched data.

Add a test for this that sets the max_match_data config to 2 and then checks to
make sure the "matched_length" and "matched_data" members are correct.

* Add modules list to yara object.

Add support for getting the list of available modules. It is available just by
accessing the yara.modules attribute, which contains a list of available
modules.

>>> print('\n'.join(yara.modules))
tests
pe
elf
math
time
console
>>>

Note: This commit also brings in the necessary defines to build the authenticode
parser, which is also done in the xor_value branch. Also, this commit updates
the yara submodule which will likely overwrite the changes done in the xor_value
so I recommend updating the submodule after both are merged.

* Update yara to 65feab41d4cbf4a75338561d8506fc1fa9fa6ba6.

* Fix test using \t in a regex.

* Fix build on Windows in appveyor.

* Actually fix appveyor builds on windows?

* Remove Python 3.5 and 3.6 which are already unsupported.
* Add Python 3.11.

For some reason the generation of the .msi installer is failing with Python 3.11.  It fails with error: error: invalid format 'msi'. The documentation the argument `--format=msi` should be correct. 

https://docs.python.org/3/distutils/builtdist.html

When building prior to this commit the dotnet module would be disabled unless
you explicitly asked for it. This is the opposite of what the default is in
libyara. Fix it by always building the dotnet module.

Tested with:

```
wxs@mbp yara-python % PYTHONPATH=build/lib.macosx-10.9-universal2-3.9 python3 -c 'import yara; print(yara.modules)'
['tests', 'pe', 'elf', 'math', 'time', 'console', 'string', 'dotnet', 'hash']
wxs@mbp yara-python %
```

Without this change the dotnet module would not be in the list.

…yor.

This argument has been removed in #222