Re-add foreign key constraint to teams table

[Antar1011]

(again, the code that created this issue has yet to be pushed into master, but I'm confident that I'll be sticking with the strategy I'm executing now, and so I'd like to make the issue before forgetting about it)

As of bd30fa6, I've removed the foreign key constraint from the teams table. This is somewhat dangerous, because I really do want to require that every "sid" in the teams table corresponds to a set in the moveset table, but leaving the constraint in leads to a few headaches, based on the overall architecture. With the constraint in place:

• The SQL moveset sink must flush before the battle_info sink. Thus, they cannot really operate asynchronously. A solution might be to have each share a session and flush together, but...
• If using the SQL battle_info sink, one is forced to use the SQL moveset sink, connecting to the same database. This is almost certainly the workflow that I'm going to end up using, but if that's the case, why did I end up defining the sinks separately to begin with?

The dangers of not having the constraint in place are:

• If there's a bug in the parsing code and the sets need to be updated, there's no automatic check to ensure that the teams table references valid sets
• When taking slices from the database (say, pulling a month's worth of battles), there's no automatic check to ensure that all the needed sets were pulled
• If the moveset sink crashes silently or has a bug or whatever while the battle_info sink keeps chugging away, the teams table will lose integrity without any error

Really, it's only the last con and the last pro that I really care about, and so far the con for having a constraint outweighs the pro, but if I ever decide to combine the sinks, I should definitely revisit this.