Support table grouping

As a user, I want to group my tables/materialized views into folders in web console, just like schemas. Usually, related tables have some common prefix/postfix or a pattern in their names for logical grouping. Web Console should achieve the folder structure with least friction.

For this purpose, suggest the following details for "Folders" feature:

• The user should be able to create "Folder"s by clicking to a button near table listing, and filling two input fields: name and regex.
• Every folder should have a name and an associated regex to capture tables/matviews.
• If the user does not have any folder, we should preserve what we have now (Tables and Materialized views on top level).
• If the user has at least one folder, then we should show the user's folders as well as a folder called "other" to list all tables that are not caught by any folder/regex
• A folder should provide "Delete folder" option when right clicked.
• Under a folder, there will be a "Tables" item if there is any matching table with its regex. Similarly, there will be a "Materialized views" item if there is any matching table with its regex. These "Tables" and "Materialized views" items will show the matching tables/matviews when expanded.
• A table/matview can appear under multiple folders if its name matches multiple regexes
• A folder can contain no items under it, and shows a placeholder indicating that the folder is empty
• Table search should be extended to find folders as well
• The number of folders, thus regexes, should be limited not to exhaust the UI by regex searches
• A regex associated with a folder should not be too greedy not to exhaust the UI
• The folder information Array<{name: string, regex: string}> should be stored in Preferences, just as instance settings (take a look at Preferences type and trace how it's used. We will use /settings with POST to merge only the folder information). Thus, in enterprise, only the users with "SETTINGS" permission will be able to add/remove folders. The folder structure should be the same across the users of the database instance.

Start by tracing the Preferences type and how instance settings are used, then inspect the table listing, table search, and /settings POST flow. Define the folder UI, regex matching and limits, permissions behavior, and persistence requirements before implementation. Done means folders, matching tables and materialized views, empty and other states, deletion, search, and shared instance settings all work as described.