Remove dependence on static files

The root `static` directory is necessary for the runtime of the Harper application in order for it to display the ASCII logo in the CLI, create and read from the default config file, and copy the contents of the default README for installations.

This has required many code paths to use `fs.read` and rely on file path resolution operations at _runtime_ to do things. This is not only confusing to manage from a development standpoint but more important very inefficient!

Moreover, certain places used the `PACKAGE_ROOT` resolution strategy by using the path of the root `package.json` file in order to reliably load static files. When I moved things over and messing with the new TypeScript-based build process, I replaced that with `__dirname` instead. This change was actually not needed and we definitely want to remove any `__dirname` references for future ESM compat. But more importantly, many places that are reading static files and managing path resolution could easily be replaced by a number of solutions.

For the ASCII_LOGO, this can easily just be a string in a JS file. Skip the fs.read in `bin/run.js` and we'll make our CLI execution faster 😄 easy win!

For the default README during installation, due to its simplicity I really think this too can be a string in a JS file. In reality I don't really see the purpose of having a root readme -- how many users are really reading that? All the info in it is in our docs. But nonetheless, this is another case of replacing a unnecessary `fs.read` serialization with either a raw string or maybe even remove it entirely (and remove the `fs.write` too).

The `defaultConfig.yaml` is a little harder to replace since its used weirdly throughout the `config/configUtils.js` file. In general though we are being very inefficient with the amount of yaml file reading and parsing happening. This change is going to be more complex than the others but the gist is to replace the default config file with a default config json object. During installation, we will have to convert that object into yaml and write it. Within `configUtils`, anywhere that is currently reading the default config file for like values can switch to regular object interaction. Switching to JSON will also give us types automatically.

Once we replace all three of these files, we can then remove the `static` directory, and likely remove the `PACKAGE_ROOT` thing from `utility/packageUtils.js` too. Furthermore, we can then likely switch to directly importing the `package.json` wherever that is happening and allow TS to handle the JSON resolution. This would have the side effect of copying the package.json into `dist` which may not be ideal so we might still have to "find-up" anyways. But we can figure these specifics out later.

Lets consider this a parent-issue and discuss the proposed changes first. If we are content, I can create individual issues and they can be chipped away at one-by-one.