Remove {update,clear}_hash from ObserverWithHashField, add hasher (ex…

…tending AFLplusplus#1019) (AFLplusplus#1028)

* libafl: Remove `{update,clear}_hash` from `ObserverWithHashField`

These methods aren't used by `NewHashFeedback`, so there's no compelling reason
to keep them in the interface. They preclude implementations of
`ObserverWithHashField` that calculcate a hash on-the-fly from a value. For
example, my use-case is to store the stdout of a process, and use
`NewHashFeedback` to only collect inputs that result in new messages on stdout.

Both of these methods are pretty suspicious to begin with - why should other
code be able to update the internal state of the observer? What are the
semantics of `update_hash`? If there are compelling reasons to keep these
methods, let's clarify their intent in the documentation.

* libafl: Return hash by value from `ObserverWithHashField`

This allows implementors of this trait to not store the hash, but rather to
compute it on-the-fly. Since `Option<u64>` is `Copy` (and quite small), and
this method is called once per execution of the target program, this is likely
to have negligible performance impact.

* libafl: Implement `ObserverWithHashField` for `ValueObserver`

This demonstrates the utility of the previous two commits. Now, `ValueObserver`
can be used with `NewHashFeedback`.

* Clippy, move to ahasher

* Oops :)

---------

Co-authored-by: Langston Barrett <[email protected]>

Bump to 0.8.2 and update versions script (AFLplusplus#828)

0.8.1 (AFLplusplus#732)

fix (AFLplusplus#703)

Bump libafl_sugar to 0.7.1 (AFLplusplus#468)

Use grammartec on crates

Update libafl_sugar Cargo.toml for publication

Bump to 0.5.0

Metadata lookup once (AFLplusplus#186)

* metadata lookup once

* fix clippy

Minor changes for 0.3.0 (AFLplusplus#108)

* update baby fuzzer in book

* readme

* readme

* book