Choose an accessor-generation strategy and/or method.

In tor_netdoc::doc::hsdesc, @Diziet says:

    // TODO HS derive this accessor
    //
    // For this and others I considered the following crates:
    //
    //  * amplify_derive, derive-getters, accessors-rs:
    //    No way to deref the Vec to [], which I think is desirable
    //    (after all, eventually these might become Box<[]>.
    //
    //  * getset: Always generates methods called `get_` which isn't what we want.
    //  * tia: Same problem.  Also strange API.
    //  * field_accessor: Works with Strings.
    //  * accessors: Always uses `get` prefix, underdocumented.
    //  * structural: Seems to be something much more reflection-y.
    //
    // derive-adhoc would make short work of this problem.

Assuming that these are our options, I think it's between amplify_derive and derive-getters. (accessors-rs only has an 0.1.0 version for now.) For the Vec issue, w'ed have to manually create the accessors for any Vecs we want to expose as a slice; IMO that's not too bad for now. I don't particularly like the documentation produced by either one, but again, "only for now".

I think it's okay to adopt either of these crates as a "good enough for now" solution since whatever we do here doesn't have any permanent API implications for our users if we shift to a better generator later.

We don't need to use this universally; I suggest whatever we do now, we deploy it as we find we need it.