Preserve tables before training

[mikeknep]

Main user-facing change

The train method is deprecated in favor of the new train_synthetics method. The latter accepts optional only | ignore lists to limit which tables are trained—the idea here is that if some table contains static reference data that you don't want synthesized, you can omit it from the synthetics workflow entirely.

The main reason for introducing this as a new method instead of optional arguments to the existing method is that the original train method resets the synthetic train state when called a second time. That felt like behavior a user might rely on, so I figured it'd be safest to leave it alone and introduce a new method (which, FYI, works "additively"—see this conversation discussing it in the context of Transforms). I also think the original method name is too generic and it's nicer to specify "synthetics" in the method name given what all Relational can do.

Note: previously we let users skip table synthesis at generate time via the preserve: list[str] argument, but of course that method is called after train/train_synthetics so we would have unnecessarily trained models for the preserved tables. The preserve argument still exists on generate and currently is not marked for deprecation—we want to see if any customers have a use case for it (e.g. I have 10 tables, I know 2 will never be synthesized so I omit them from training, later during generation there is one more table I want to preserve with source data instead of synthesizing. TBD.)

Delete models method

The same conversation with @pimlock on #109 got me thinking that we should have a delete_models method—it seems like a useful thing to have alongside the only | ignore params. It was a pretty straightforward thing to add, but we could also skip it / remove it from this PR. @gracecvking any thoughts?

EDIT: decided not to include this, can be added sometime in the future if/when a well-defined use case arrives.

Internal improvements

• Previously we had been keeping track of which columns were used in model training so that the ancestral strategy could be sure not to include those columns in seed data. In Seed fix #101 we moved the logic of which columns can be used in seeding to the core RelationalData class. Here, I realized since that info is calculated and cached there, we don't need to carry it in the MultiTable state and backups—we can just ask for it again—so training_columns is removed from several places.
• Previously we had a dedicated field related to synthetics generate state called missing_model for tables that didn't train successfully. However, since we now allow users to omit tables from training, we can no longer say "if we can't get a completed model, treat it as failed"—we now need to know if the table attempted training unsuccessfully, or was deliberately omitted. Fortunately, like above, we can calculate this from other data in state, so missing_model is dropped.
• We now create and upload the training data archive file before submitting and waiting for the model training jobs

[gracecvking]

LGTM

[tylersbray]

I had questions but not concerns 🚢

Oh, this PR had a long README but I didn't see a ton of docstrings. And maybe as a bigger thing, is there a confluence page with an architecture/state diagram/strategy walkthrough...?

[pimlock]

LG!