CachingObjectConverter should have max cache items for safety (to avoid OOME in corner case)

I found a corner case in a real use case, causing OutOfMemroyError.
Here's the detail:

1. A project implements an HST REST service which queries published documents from repository, converts nodes to HippoBeans (using ObjectBeanManager), and commits batches (size of 100) of indexing those beans to Solr server.
2. The HST REST service is supposed to be executed every night for instance.
3. Now, during the step 1, the HST Content Beans are all cached in CachingObjectConverter because the whole process to index N documents are in the same request processing cycle.
4. Therefore, if there are 2K documents, CachingObjectConverter keeps 2K beans, which might consume up to 300-512MB or more at runtime, depending on the document designs.
5. By the way, the reason why HST Content Beans are chosen to index documents into solr was because they wanted to take advantage of HST Solr Client library which takes HST Content Beans with a specific annotations. Therefore, this OOME is inevitable in many cases for normal developers (who are using ObjectConverter through HstRequestContext) when a customer wants to a combination of HST REST + HST Solr Client (+HST Content Beans).

I think, for safety, CachingObjectConverter should have a default max cache size. e.g, 100.

By the way, a workaround could be using HstRequestContext#getContentBeansTool()#getObjectConverter() only somehow instead of getting ObjectBeanManager from HstRequestContext, but it doesn't look really good.