1. FAILED => FAILED transition on RMAppEventType.APP_SAVED and KILLED =>
KILLED transition on RMAppEventType.APP_SAVED are defined. It fixes the
problem pointed by @Bikas.

2. In addition, I found there's a problem in RMApp state transition in
the RM restarting scenario. The stored MRApp will be recovered, an RMApp
instance will be created, it will transit to NEW_SAVING and be stored
again with the previous patch. To fix the  problem, "isRecovered" is
defined in RMAppImpl, and is set to true when RMAppImpl#recover is
called. Then, on RMAppEventType.START being received, NEW => NEW_SAVING
if the RMApp instance is not recovered, NEW => SUBMITTED otherwise.

3. Addition test cases are added in TestRMAppTransitions to test the
aforementioned transition rules.

4. TestRMRestart should have traced the problem of saving the RMApp
instance which is recovered again.  However, it didn't failed the test
case with previous patch because MemoryRMStateStore didn't throw
exceptions when storing a duplicate application/attempt. Therefore, in
the newest patch, MemoryRMStateStore will through IOException when the
application/attempt has already been stored, which is consistent with
the behavior of FileSystemRMStateStore. Then, the current test case of
TestRMRestart can trace the problem of saving the RMApp instance twice.