For fuzz targets that use `libfuzzer_sys::fuzz_target!(|arg: &[u8]| {})` directly
without `#[macro_use]`ing `libfuzzer_sys`, the compilation failed:

error: cannot find macro `fuzz_target` in this scope
   --> [$HOME]/.cargo/registry/src/github.com-1ecc6299db9ec823/libfuzzer-sys-0.4.2/src/lib.rs:161:9
    |
137 | / macro_rules! fuzz_target {
138 | |     (|$bytes:ident| $body:block) => {
139 | |         /// Auto-generated function
140 | |         #[no_mangle]
...   |
161 | |         fuzz_target!(|$data| $body);
    | |         ^^^^^^^^^^^
...   |
207 | |     };
208 | | }
    | |_- in this expansion of `libfuzzer_sys::fuzz_target!`
    |
   ::: fuzz_targets/bare.rs:3:1
    |
3   | / libfuzzer_sys::fuzz_target!(|data: &[u8]| {
4   | |     // fuzzed code goes here
5   | | });
    | |___- in this macro invocation
    |
    = note: consider importing this macro:
            libfuzzer_sys::fuzz_target

Use absolute path to fuzz_target! macro in macro recursion

This is not ideal, but it does provide two things:

1. It fixes bizarre linker errors about missing `sancov` symbols.

2. It allows LLVM to do inlining that it otherwise refuses to do. For some
reason, when sanitizers are enabled, LLVM refuses to inline across codegen
units. This is a problem because trivial methods like `Vec::len` won't be
inlined, resulting in 100x slowdowns.

`cargo fuzz` already restricts its builds to a single codegen unit, so we might
as well do the same thing in CI here.

See #90.

Update libFuzzer to llvm/llvm-project@60e32a1

This commit migrates CI to using the `cargo fuzz` binary with its
settings for compiling Rust code to avoid mismatches like the codegen
unit issue found in #89

Migrate to using `cargo fuzz` in CI