Increment the SharedClasses cache generation number

When new bytecodes were added in #1831 for the truncated returns,
the SCC generation number wasn't incremented which can lead to
crashes.

Currently the VM will attempt to destroy and recreate the SCC
if the SHA in the header is different but if can't, it will
continue to use the cache.

The only sure way (today) to prevent this issue is to increment
the cache generation.

Do this now to prevent VerifyErrors due to unknown bytecodes
while we work out the right behaviour.

issue: #5380

Signed-off-by: Dan Heidinga <daniel_heidinga@ca.ibm.com>

runtime/shared_common/OSCache.hpp

@@ -1,5 +1,5 @@
 /*******************************************************************************
- * Copyright (c) 2001, 2018 IBM Corp. and others
+ * Copyright (c) 2001, 2019 IBM Corp. and others
  *
  * This program and the accompanying materials are made available under
  * the terms of the Eclipse Public License 2.0 which accompanies this
@@ -61,7 +61,7 @@
 #define OSCACHE_LOWEST_ACTIVE_GEN 1
 
 /* Always increment this value by 2. For testing we use the (current generation - 1) and expect the cache contents to be compatible. */
-#define OSCACHE_CURRENT_CACHE_GEN 35
+#define OSCACHE_CURRENT_CACHE_GEN 37
 
 #define J9SH_VERSION(versionMajor, versionMinor) (versionMajor*100 + versionMinor)