Meterpreter session architectures not tracked in MSF properly

Once a Meterpreter session has been established back to MSF, it's possible to migrate from one process to another, as we know.

Unfortunately there's a small issue where during or after migration, no steps are taken to make sure that the new architecture of the session is tracked. Ideally, we should update the UUID of the session to match the new architecture, but we don't.

This doesn't prove to be an issue while using an established session that has been migrated from one arch to another, but it does cause issues when that session is put to sleep/split and then returns to MSF.

When MSF gets the session coming back, it believes it to be the same as the original architecture, even if it's no longer then case thanks to migrating. I'm not sure yet if this is just down to the fact that we don't update the UUID when migrating, or whether our handlers are not correctly checking the UUID in stageless connections once they've come back in. I think we should be doing both.

Steps to reproduce

1. Set up a reverse_* handler of some kind (I used to reverse_https) that's x86 and has ExitOnSession set to false. Kick it off with run -j.
2. Create a matching payload/binary.
3. Execute the payload/binary on an x64 system, get a session.
4. Check to make sure sysinfo says Meterpreter : x86/win32.
5. Run uuid to see the current UUID details
6. Migrate the session to an x64 process.
7. Run sysinfo again and notice it changes to Meterpreter : x64/win64.
8. Run uuid and notice that the architecture returned is still x86=1/windows=1 as it was before.
9. Put the session to sleep for 1 second using sleep 1.
10. Wait for the session to come back, and interact with it.
11. Run sysinfo again and notice that we now have Meterpreter : x86/win32 again.
12. Run uuid and we still have the same details.

At this point we have mixed architecture things going on, which can result in bad things happening. If the user loads an extension at this point, they will see crashing happening as x86 binaries are thrown at x64 sessions.

Suggested approach

I think we should:

1. Make sure we update the UUID when migrating so that the arch matches.
2. Validate the UUID when stageless sessions are received, and/or immediately after staged sessions have finished loading their first stage.

If in doubt, we should always ask Meterp instead of trying to keep track of it at the MSF side.

Ping @hdm and @busterb since we chatted on IRC about it.

Thanks!