Check access rights of config files before opening them

[DonatJR]

fixes #75

• Configurator and Service now check the access rights of the config file before opening / processing them further
• The list of available configs in the Chooser is now based on registry entries written by the Configurator
• Configs are now all stored in the same folder to make it less likely a registry entry gets invalidated

@bencikpeter Could you take a look at the CheckConfigAccessRights function in the CageService? You have the most experience with the Windows API in this regard https://github.com/SharkCagey/HTWG_shark_cage/pull/85/files#diff-c70ab997f5ee033d6f6d8bd7ca7264b8R243

[SailReal]

Oh and we have a conflict file "SharkCage/CageChooser/CageChooserForm.cs"

[DonatJR]

@SailReal

1. that was my original plan, but then I wanted a nice refresh icon instead of just plain text which means doing it myself or finding a good looking icon with a suitable license - too much work for now 😅 the list also refreshes on restart so I don't think the button will be absolutely necessary
2. I will constrain it to the current size. Getting all controls to size with the form is possible I think, but I don't know how to do it (yet) -> too much work ;)
3. Great idea!

[bencikpeter]

@DonatJR Sorry for a late reply, I somehow overlooked that mention

I had a look at CheckConfigAccessRights And I have fer remarks

• Is there any particular reason for using ::LocalFree and ::LocalAlloc? Documentation states that

  The local functions have greater overhead and provide fewer features than other memory management functions. New applications should use the heap functions unless documentation states that a local function should be used.

        so I´d assume it´s a better idea to use those?

• variable name of access_rights_okay is a bit misleading if the value is false. Maybe something along the lines of access_rights_status would be more appropriate?

• from a functional point of view, I don´t see anything wrong with it, it should be fine.