This is the recommended way of referring to the current crate in a macro.

This PR adds more benchmarks so we can get and accurate idea about two
things:

  - What is the cost of having to zero the buffer before calling
    `getrandom`?
  - What is the performance on aligned, 32-byte buffers?
    - This is by far the most common use, as its used to seed
      usersapce CSPRNGs.

I ran the benchmarks on my system:
  - CPU: AMD Ryzen 7 5700G
  - OS: Linux 5.15.52-1-lts
  - Rust Version: 1.62.0-nightly (ea92b0838 2022-05-07)

I got the following results:
```
test bench_large      ... bench:   3,759,323 ns/iter (+/- 177,100) = 557 MB/s
test bench_large_init ... bench:   3,821,229 ns/iter (+/- 39,132) = 548 MB/s
test bench_page       ... bench:       7,281 ns/iter (+/- 59) = 562 MB/s
test bench_page_init  ... bench:       7,290 ns/iter (+/- 69) = 561 MB/s
test bench_seed       ... bench:         206 ns/iter (+/- 3) = 155 MB/s
test bench_seed_init  ... bench:         206 ns/iter (+/- 1) = 155 MB/s
```

These results were very consistent across multiple runs, and roughtly
behave as we would expect:
  - The thoughput is highest with a buffer large enough to amoritize the
    syscall overhead, but small enough to stay in the L1D cache.
  - There is a _very_ small cost to zeroing the buffer beforehand.
  - This cost is imperceptible in the common 32-byte usecase, where the
    syscall overhead dominates.
  - The cost is slightly higher (1%) with multi-megabyte buffers as the
    data gets evicted from the L1 cache between the `memset` and the
    call to `getrandom`.

I would love to see results for other platforms. Could we get someone to
run this on an M1 Mac?

Signed-off-by: Joe Richey <joerichey@google.com>

… sources (#276)

* add description about Cargo js feature
* add note about different crate types
* clean up
* Fix wording/grammer
* Remove "Indirect Depenencies" section
* Note that libraries shouldn't add their own JS feature

Signed-off-by: Joe Richey <joerichey@google.com>
Co-authored-by: Mauri Mustonen <mauri.mustonen@hotmail.com>
Co-authored-by: Joe Richey <joerichey@google.com>

Now we look for the standard Web Cryptography API before attempting to
check for Node.js support. This allows Node.js ES6 module users to add
a polyfill like:
```js
import {webcrypto} from 'crypto'
globalThis.crypto = webcrypto
```
as described in #256 (comment)

Signed-off-by: Joe Richey <joerichey@google.com>

This allows users to get an actionable error message about this
particular problem. We also add detection for this problem.

Signed-off-by: Joe Richey <joerichey@google.com>

Signed-off-by: Joe Richey <joerichey@google.com>

This call throws an exception if module isn't defined.

Signed-off-by: Joe Richey <joerichey@google.com>

Signed-off-by: Joe Richey <joerichey@google.com>

Rework JS feature detection

Signed-off-by: Joe Richey <joerichey@google.com>

Also updates the changelog

Signed-off-by: Joe Richey <joerichey@google.com>