Add Value.date field

[jpmckinney]

The unit of an amount is not only the currency, but also the date on which it was set, due to inflation. To be able to correctly sum values over longer periods of time, especially in contexts with high inflation, it is important to store the date on which the amount was set.

For the definition, we can see https://en.wikipedia.org/wiki/Value_date

cc @duncandewhurst

[jpmckinney]

Noting that prior issues relevant to this include #384 continued from #277

[jpmckinney]

Perhaps a more relevant reference: https://www.investopedia.com/terms/v/valuedate.asp

[jpmckinney]

In OCDS we have values in budget, tender, award, contract, transaction, and unit (which it itself used in the items of tender, awards, and contracts).

For awards (and award items) and transactions, we have awards.date and transactions.date. For tender (and tender items), we will have datePublished #892. I'm not aware of a scenario in which these values would change (except to make a correction on a data entry error), so those date fields are sufficient.

For budget, we do not have a date field, so there could be a use case for a value date, though I don't know enough about government budgeting to know if such details are commonly tracked. (I think it is not.)

That leaves contract and contract items. The values of a contract can be modified during implementation, for which we will not have the updated date (we only have dateSigned). That said, a contract whose value changes is likely paid out in installments, and so having a single date for the total value will be misleading. All told, it's better to rely on either award values, or on transaction values for analysis of contract values.

So, I think this leaves no use case for Value.date. As such, I'll close the issue, but I can re-open it if we find a use case.