Allow iterating over compiled ruleset before scanning

[jpohls1]

This PR fixes #135. It includes an updated tutorial.rs showcasing how to iterate over the compiled ruleset and disabling certain rules. This feature is crucial for implementing custom rule filters in client-side applications.

Please let me know any feedback and thanks for creating these bindings!

Implementation details

On the new get_rules.c file

The approach taken by existing iterators such as TagIterator is difficult to apply, because the rules_table is not properly exposed via bindgen. We just have a binary blob to work with:

pub struct YR_RULES {
    pub _bindgen_opaque_blob: [u64; 10usize],
}

Therefore, I created a new file get_rules.c which uses the yr_rules_foreach macro to retrieve the rules from the ruleset. This is inspired by the Go bindings.

Since we need to compile this file in any case, the cc build-dependency is now mandatory, hence the changes in the Cargo.toml and build.rs.

On the new RulesetRule struct

The existing Rule struct represents a rule that matched during a scan. It would have involved some more refactoring to lift this assumption. I went with the less invasive change here and created a new RulesetRule struct.

[vthib]

The YR_RULES type is opaque since 43d0be1

It was made opaque mostly for codegen size reasons, so we can totally decide to expand it once again. This would give access to the rules_table field, which would be imho preferred, as it avoids adding C code for the bindings.

[Hugal31]

I am not a big fan of adding a mandatory dependence to cc. Is yr_rules_foreach the only public interface we got or can we safely re-implement it in Rust?

[jpohls1]

Cool, didn't know about 43d0be1, thanks @vthib. Removed the line that made YR_RULES opaque from build.rs and implemented a RuleIterator in the same spirit as the existing Iterators in the code.

@Hugal31 please let me know whether further changes are required.

[Hugal31]

You'll have to include the generated binding files (look at the bindings Github action).

I will probably rename Rule to MatchingRule later (with a deprecation period for Rule).

[jpohls1]

@Hugal31 could you please release a new version that includes this change?