1) Hard drives tend to be very large these days and FileMaker tables can expand to hold millions of records so you may not need such an archive system as much as you might think. There are ways to limit access to the records on a record by record basis so you can "lock down" the records for a past project while keeping them in the same table. Nevertheless, it is indeed possible to set up a system where the data from your current tables are exported to other tables (either in the same file or a separate file) and then deleted from the original tables. Import records can be used in a script to achieve this result.
2) I think this can be done if you install a copy of FileMaker Pro with a volume license key as each logged in user will be counted as a separate user and if they don't log out between sessions, a single "seat" license would trigger an error message and quit fileMaker for the second user. Note that this is not needed if user 1 quits fileMaker before User 2 attempts to access it.
3) What you are discussing is also referred to as 'locking' a record. I refer to it as "edit locking" to distinguish from "locking" a record in manage | security like I briefly mentioned in 1) above. Multiple users can use the same layout at the same time, but they cannot edit the same record at the same time. When one user clicks or tabs into a field on a layout, that record is opened for editing and other users are locked out of making any changes to the record. If a second user attempts to modify the record, FileMaker will display an error message that <user name> is modifying this record. <User name> is a name you specify in preferences so you want to give each system account that will use your database a unique user name in order to determine who has "edit locked" a particular record. Scripts performed by one user will also trigger a similar message if the script attempts to modify records 'edit locked' by others unless you've enabled set error capture in the script--in which case the only way you know that the records did not get updated is when you inspect the records. (For this reason, I use Set Error Capture as little as possible in user performed/triggered scripts, turning it on and then back off as soon as possible.)