ctest: add support for modules

[dybucc]

Description

Add support for (currently) parsing and filtering Rust modules found in
the target crate to test. This is supposed to provide scaffolding for
multiple open feature requests that depend on ctest having support for
modules.

I decided to open this before finishing up work on generating proper
tests on both C and Rust sides, because I am not sure if I should just
let the user deal with including a cohesive set of modules that do not
cause item resolution conflicts, or if I should instead generate
separate tests for each parsed module.

Edit: the above paragraph really goes to say that I am not sure
whether I should generate multiple test templates while recursing
through the modules in TestGenerator::generate_files, or if I should
instead recurse through them in TestTemplate::new (with the passed
FfiItems) and return a collection of test templates for each parsed
module that has not been skipped.

cc @tgross35 @mbyx

Update

I have changed the way we parse item identifiers, and more specifically,
their absolute paths without crate at the start (e.g.
foo::bar::ctime() instead of crate::foo::bar::ctime().)

This should make filtering continue working as-is right now for items,
but allow filtering on items in nested submodules by using an
appropriate string matching something like the above example.

Checklist

• Relevant tests in ctest/tests and ctest/src/tests.rs have been
  updated
• Tested locally (LIBC_BLESS=1 cargo test -p ctest);

@rustbot label +stable-nominated