Refactor: Store all donations for all funds in a single table

[yuriytkach]

The single table design is likely more appropriate. Here's why:

• Moderate Data Volume: The number of records per fund is not so large that it would necessitate separate tables for performance reasons.
• Temporary Funds: The temporary nature of funds means that the number of active tables would continually grow, increasing management overhead.
• Access Patterns: Most queries are for the current fund, which can be efficiently handled with a GSI (Global Secondary Index).
• Simplicity: A single table is simpler to manage, and you can use GSIs to efficiently query for donations related to a specific fund.

Arguments for Separate Tables (good arguments, but something that we don't need):

• Isolation: Each fund is completely isolated from the others. This can simplify some aspects of data management, such as access control, backup, and deletion.
• Schema Flexibility: If different funds might have slightly different data requirements, separate tables can accommodate these differences more easily.

Since we already have separate tables, we would need to write a script that first populates that newly created table with data from existing donations tables. We have switch in lambda to single donation's table, deploy it and then run the script. For a short time list of donators won't be visible, which is fine.

[yuriytkach]

Fixed in #240