Improvements to Platform/Arch change workflow

What is the feature you'd like to have?
Sometimes, a user might want to change the platform and/or architecture of the database they are working with. We should have an obvious and well-supported way of doing this (that is also, ideally, well-documented).

Is your feature request related to a problem?
This is a more common issue with firmware as you might not know, before starting your RE, what the platform is or whether you need a specific version of an architecture. In this situation, you might think that you should:

bv.platform = binaryninja.Platform['linux-aarch64']

...but, as far as I can tell, that doesn't get persisted in the database. So, if you save and re-open, your change is gone.

Other users might think the right answer is to close the database, use Open with Options to re-open it, and change the platform that way. In my experience, however, this simply causes a huge amount of things to be duplicated (e.g. you have two copies of a ton of functions, one with the old platform/arch and one with the new, and only one of them shows up in the symbols view because they share a start address).

It's not actually clear to me what the 'right' way to do this is. I think it might be:

1. Close the bndb
2. Open the original file with options
3. Set the things you want
4. Import from BNDB in the new database and copy everything over that way (if you can)

Unfortunately, that's a little clunky and I believe would leave a fair amount of data behind.

Are any alternative solutions acceptable?
Any solution that retains as much data as possible while automating as much of the process of swapping platforms/architectures should be viable here. It's even possible this is already super well-supported and I just don't know how to do it correctly! In which case, all we need to do is have a specific docs section on it (or highlight an existing one better, if I've missed it).

Additional Information:
This has come up multiple times in the last 6 or so months while chatting with Enterprise customers, not to mention a few people on Slack as well.

Start with the Platform API around bv.platform and the Open with Options workflow described in the issue. Investigate how platform and architecture changes are persisted in BNDB files and what happens during import; done should be an agreed, supported workflow that retains existing analysis data or clearly documents the correct procedure.