Improve relaunch merging in activity thread.

To reduce the number of times that we load resources based on
configuration changes ActivityThread employs an optimization
strategy that merges relaunch operations. If it receives a
relaunch request why one is already queued, it will just update
the queued request instead of creating a new one. Unfortunately
this breaks the guarantee of executing lifecycle events in the
order they were received.

Consider following scenario of requestes from Activity Manager:
1) relaunch the activity in not resumed state;
2) resume the activity;
3) relaunch the activity in resumed state.

The Activity Thread can process these commands in following order:
1) receive the request to relaunch in not resumed state;
2) receive the request to resume the activity;
3) receive the request to resumed state, update the exisiting
request;
4) execute the request to relaunch in resume state;
5) execute the request to resume.

This causes the activity to perform resume twice.

Since we need the merging of relaunch operations for performance
reasons, we need to introduce a secondary mechanism for ordering
of lifecycle requests. Relaunching, pausing, stopping and resuming
receive a sequence number based on when the request was received. If
the last executed sequence number is higher then the operations
sequence number then the operation will be dropped.

In the above scenario the sequence number would be:
1) request to relaunch not resumed receives seq + 0;
2) request to resume receives seq + 1;
3) request to relaunch resumed receives seq + 2;
4) execution of of request to relaunch resumed set current sequence
number to seq + 2;
5) since seq + 1 < seq + 2, then the execution of request to resume
is prevented.

Bug: 24806374

Change-Id: Ia520dd1aa215827d4172a9891a7cc01db2ce627e