Manually implement Zeroize

[gardk]

Removes dependence on proc-macros when enabling the zeroize feature.

As the macros previously made sure that all fields were zeroed, I opted for destructuring self in the impls so that a compile error will be triggered if a field is added and not handled.

Used as_mut_slice().zeroize() on arrays even though they implement Zeroize. This is because the implementation on slices zeroes the whole slice then issues an atomic_fence() call, while the array implementation calls it for every element. Don't know and haven't tested if there's a difference in optimizations. Both implementations produce the same result anyway :)

[oconnor663]

Thank you! This seems reasonable. Could you help me address a few points?

• Is there a measurable clean build time difference before and after?
• Can you confirm that something fails (either the build or existing tests) if any of these impls is deleted?
• Could you add inline comments next to spots where you're doing destructuring, with a quick explanation of why you're doing it?
• Similarly, could you comment on the array vs slice distinction inline, so that future readers (i.e. future me) will know why the difference matters.

[gardk]

Added comments. Reverted to array implementation as the atomic_fence() call I was so worried about doesn't actually generate any code, and looking at the assembly the array implementation looks much better. No real difference in performance between the two either way.

Here's the difference in clean build time on my machine.

# Manual
Time (mean ± σ):      1.356 s ±  0.202 s    [User: 2.496 s, System: 0.591 s]
Range (min … max):    1.197 s …  1.806 s    10 runs

# Derive
Time (mean ± σ):      3.720 s ±  0.212 s    [User: 9.807 s, System: 1.430 s]
Range (min … max):    3.564 s …  4.298 s    10 runs

Every impl is already used by existing tests added in #309, removing any one of them causes those to fail compiling.

[oconnor663]

Oh wow yeah, that's a huge difference. Looks great, thanks again!