Additional wishlist for currency stuff.

The currency stuff is going to be complicated, but I agree completely we
should leave it wishlist'ed.

Plural pronouns for singular annoys me.

I really believe in gender fairness and fluidness in prounouning, and I
get why "they" is always better to use, and that the "one's request"
construction is too tortured. So, I tend to just write everything in
plurals if possible which keeps 'they' but makes the number
grammatically agree.

Yes, I know that the ADT made "they/them used as singular" as 2015 word
of the year. (see
https://en.wikipedia.org/wiki/Word_of_the_year#American_Dialect_Society

so maybe some nun slapped the table too hard with her ruler when made
some plural/singular mistake with a pronoun when I was in grade school,
but I have a compulsive need to change everything to plural when I see
"they" and am editing a document. ;)

Additional request state: Pre-Approval

Many travel policies, for example, require that certain expenses be
approved before tickets can be purchased. An example from Conservancy's
travel policy include: hotel bookings beyond the GSA/Dept-of-State Per
Diem hotel rate, and flights that exceed the with-$100-of-cheapest rule.

As such, requestors need the ability to request preapproval.

These changes herein committed, however, do *not* account for the fact
that a request may already be "In Progress" when another expense comes
up. An example of that is a flight was booked already in policy and the
requestor, and uploaded, and the requestor then discovers later that the
hotel is out-of-policy and needs preapproval. We can perhaps ignore
this scenario for the first specification of this to avoid
feature-creep, but I wanted to flag it as a potential issue for future.

The work around might be that the Bookkeeper is allowed to move a
request between any state to another, so the work-around in this
specific instance may have to require an out-of-band conversation
between bookkeeper and requestor. That's not disaster.

member => requestor

The requestor for payment may or may not be a member or affiliated in
some way with the organization.

Slightly increase scope: include payment requests

The project should really include outgoing payments along with it.
Submitting an invoice for payment as an external party is really just a
"base case" of a reimbursement request.

The only complication I can imagine this adds is allowing the general
public to create an account on the system, or allow for anonymous
submission, which might lead to spam concerns in deployment.

I believe these issues should be easily mitigated and will not
drastically increase scope of the project.

As part of this actual change to the text, some wordsmithing and changes
throughout to s/reimbursement/outgoing payments/ and other similar
changes are made.

Refresh the front page.

Remove outdated information, and update other tone of voice to better
reflect the current state of the project.