Refactor how the default startup data works

[dEhiN]

Created this issue while working on #20 because realized that currently the way the default startup data is handled can be refactored to be a little more efficient and forward-thinking via 2 changes:

1. The function generate_default_startup_data in the data_generate module directly reads in the default startup data JSON file, which is called _defaultstartup.json. However, since there is the json_reader function in the jsonfn module, there is no need for this. Additionally, the file data is read in directly using a try-except block, which could cause troubleshooting problems down the road, as it's another area where an exception could happen. Since the json_reader function is already built to handle all troubleshooting related to reading in JSON data, and the file it uses is passed in as arguments, it will make the code more robust to refactor the function generate_default_startup_data to call the json_reader.
2. The variable used to hold the filename _defaultstartup.json is hardcoded in the function. In case the name of the file is changed in the future, it may be better to have a single global variable of some sort in the main comp_start app, which any function that's working with this file references.

[dEhiN]

Adding the 2 changes as tasks that can be checked off:

• [x] 1. Refactor the function generate_default_startup_data to call the existing function json_reader for reading in any JSON file data, rather than using a try-except block to do it directly.
• [ ] 2. Extrapolate the location of the default startup data JSON file to be stored in only one place - the main comp_start app.
• [ ] 3. Change any places where the default startup data JSON file is handled to use the new location for grabbing the actual filename.

[dEhiN]

Copy-pasting from commit 359aa2e:

While testing the changes made in the previous commit, it became apparent that if the default startup data JSON file was blank, the program would print out the appropriate error message but then would continue execution.

_This was because, while functions like json_reader would return a boolean as one of the return values to indicate if the function was successful, both functions generate_default_startup_data and generate_new_json_data wouldn't return any boolean value._

Both functions were refactored to return a boolean value, which is then passed up the stack and accounted for in the main loop.

This was tested using a completely blank default startup data JSON file and the following is outputted, after which, execution returns to the main loop:

ERROR
The following error was encountered:

Function: generate_default_startup_data
Message: Unable to read startup data. Error information is below:
JSONDecodeError - Expecting value: line 1 column 1 (char 0)

There was a problem generating the startup data!
Please see the error details above.

[dEhiN]

Tested the following scenarios and confirmed the proper error handling occurs:

1. Blank JSON file
2. Single, empty JSON object
3. Malformed startup data using only the JSON key TotalItems
4. Malformed startup data using only a single startup item

In all cases, a proper trail of error messages was printed out indicating, from highest function to lowest, each of errors along the way. The first error message, printed from the function json_reader displayed the correct issue in each of the tests above