Reorganize repositiory's data files

[Y3drk]

Problem

We need to make it more intuitive and simple for external contributors to figure out what's going on in the repo. Currently, there's too much of a learning curve.

Goals

Refactor how the data files are organized in ENSAwards to make it more welcoming for external contributors.
Review each of the following and ensure it is optimized:

• Terminology
• Data model relationships
• Comments in code
• File names / how code is distributed across directories / files.

Initial Ideas

Loosely copied from this Slack thread. Good as a starting point, but we should adapt as we change things.

• Instead of putting all apps into a single file named apps.ts, what if we had a directory structure such as data/apps/{app-name}.ts where each app had its own distinct file. And then a file such as data/apps/index.ts that imports all the app definitions into an overall array of APPS.
• Alternatively directory structure such as /data/apps/{app-name}/ so that each app gets its own full directory. Then the definition for the app itself can go into an index.ts inside each directory. Likewise, each protocol could go into /data/protocols/{protocol-name}/. With such a directory structure, you could do things like

[lightwalker-eth]

@Y3drk A few ideas:

1. It may also be interesting to move the data folder up one level, so that it's no longer nested under src. I think this would help to more cleanly identify how those files are for the data of the site, rather than the "source code" of the site. Yes, technically they are code, but conceptually they have a distinct role. I'm not sure if moving them out of src might cause some problem with some tooling that expects them to be in src. If so, please ignore this suggestion. Not a big deal.
2. Could we apply logic, at least on a few specific categories of pages (not all), so that when you click "Edit on GitHub" in the ENSAwards UI, instead of those buttons always redirecting to https://github.com/namehash/ensawards/blob/main/CONTRIBUTING.md we might instead:
   1. Redirect to the specific data file on GitHub that's most relevant.
   2. Add a comment up in the header of each data file that suggests reading the full CONTRIBUTING.md file for additional advice on making contributions.

Goals:

• Suggestion 1 above: For people who just want to contribute data, and not change the code, it will be nice if they don't need to open src.
• Suggestion 2 above: Make the "Edit on GitHub" buttons feel more actionable. When they link to a big CONTRIBUTING.md file with a lot of instructions I believe it can feel overwhelming to make a simple casual contribution. However, if they open up to a file where it's intuitive how if I change the value on field X I will achieve the goal I want, then I think we will encourage more contributions.