Decide what to do with AZ_FUNC_TABLE_INFO_CACHE_TIMEOUT_MINUTES

[Charles-Gagnon]

This was added in #395 but then the test it was added for was later remove d in #560, so it's not currently being used. And it's not documented anywhere for customers to be able to use themselves.

Questions we should ask:

• Do we still want/need this? It happened to be useful in Can't update a row in table with IDENTITY as primary key #891, but that's a bug and not something we normally intend
• Do we need this caching at all? Can we refactor the bindings to get all the column info for a table and be fine with that never changing for the lifetime of the function? (we already say that changes to the table while a function is running may have unexpected behavior)

If we do keep it, we should consider moving the parsing logic out of the UpsertRowsAsync method. We only need to calculate the value once at startup - so calculating it each time an insert is done is just wasted effort.