Import Export Functionality for contents in input.db

[Govind-S-B]

Describe the problem or issue the feature resolves

Right now there is no way to backup data entered for reuse ( particularly the Halls data which is reused often ) other than the data persistence thanks to the input.db

Mention and describe the feature

There needs to be some export import functionality where I can store all the data for later use.
It should also be human readable to an extent so that they can edit the hall values and comment out temporarily unavailable halls without going into the application

A sample format which contains all the Halls available to the College

Halls:
  SJ210 - 34
  # SJ211 - 64 commented out as hall temporarily unavailable
  SJ105 - 50

It would be nice if we could comment out a whole block of halls as we can then do things like blocking all halls of SJ and SX since they are not available as a whole

Mention the merit of implementing the feature and the improvements it offers

Sharing Data
Editability

(Optional) Suggest a solution and ideas for implementation

The conversion from the db file to savefile and vice versa need not be necessarily implemented in flutter , we can make a python / rust script which does the job similar to how the generate button works , the script can convert the save file to/from input.db (but then we need to plan out which program is accessing the db at any given time to avoid conflict with resource being used by another process).

Or we could just do this in flutter/dart and avoid the entire pain

Additional Information

The format can be something like TOML or YAML ( a human readable format that also allows commenting out sections ), JSON doesnt seem to support comments.
Another option is to define out own custom format and have a custom function for parsing the data to/from .

[officiallyaninja]

Instead of adding a whole new layer to this that we have to keep consistent with DBs, why not just add a column to the halls table that sets availability.
So unavailable halls remain in the db but wont be considered for seat allocation.

[Govind-S-B]

So essentially , instead of having to re-enter data all the time , the input.db can just contain all the halls and the user can disable or enable the halls as needed

since subjects data change often during each generation , those need not be backed up

[Govind-S-B]

If the input.db fields are being changed for adding disabled/enabled halls , maybe club it together with #57 . Also rework on the table such that its possible to bulk select multiple rows and have combined actions on them