GUI: in data catalog don't use restrictions, add project instead of database

[petrasovaa]

This PR modifies data catalog:

• remove restrictions that prevented users from editing outside of current mapset. Base on experience, this restriction is unexpected especially for new users. I removed the option to change it completely, the internal code I kept as is, just turned off the restriction.
• I removed adding database path and instead added an option to add existing project. This is consistent with the way we are trying to de-emphasize GRASS database. I had interactions in the past where students were trying to add a project, but added it as database so it didn't work. Now the newly implemented adding of project tries to be more clever, thanks to the existing functionality in the library it's easier to test whether the project is valid and if not it tries to test whether the directory above or below is a project and reports useful message if not. I also changed location to project in those messages. One side effect is that when you add a project, the database is added and reloaded so all projects in that path are automatically added as well.

[wenzeslaus]

I agree that the expectation for data catalog is to manage data in general, i.e., making changes to other mapsets and projects. The mapset-only-edits restriction is primarily meant for the individual tools, so that a tool or a script don't destroy unrelated data, but that's different for a multi-project management tool like the data catalog.

If we want to add opt-in restriction for some reason, it would be relatively easy to get the functions from here if needed, but the GUI interface for that would likely be different anyway.