chore: add "user_configs" db table

[aslilac]

• Adds a "user_configs" table

• Moves the data from the "users"."theme_preference" column to this new table as a bit of a proof of concept

The idea is that this table will enable future feature development to have a nice spot to put user specific settings, like storing the state of dismissed notification banners, or other UI personalizations that we may add in the future. It could even be used to remember values from partial form completions, or all manner of other things, (and in a place where they can later be invalidated by the backend, rather than put in localStorage)

[aslilac]

pls don't close my pr github

[ethanndickson]

Since we're no longer sending the theme_preference in api/v2/users responses, should this be labelled as a breaking API change?
Context: coder/coder-desktop-macos#91

[johnstcn]

@ethanndickson would it suffice to re-add the field in the /api/v2/users response but mark it as deprecated?

EDIT: this was already done as part of this PR, the only other change was adding omitempty.

[ethanndickson]

I think the change is fine honestly, but if it's breaking our own Coder integration (desktop), it's possible it could break someone else's.
..In saying that, I doubt people are actively consuming theme_preference. If it does break something, it's probably just because they expected the field to be present like I did on desktop.