Add projectName and projectShortName fields

Right now, there is no explicit, non-heuristic way to distinguish which chains are part of the same "project" or "system of networks" (i.e. which chains are "siblings" — maintained by the same community, run by the same validators, etc.)

I want to be able to look at e.g. ETH Mainnet, Ropsten, Kovan, Rinkeby, and Görli, and be able to automatically determine "those are all Ethereum"; and then look at e.g. ETC Mainnet, Kotti, Morden, and Mordor, and be able to automatically determine "those are all Ethereum Classic." I want to be able to build hierarchical navigation logic where you can first pick a project, and then pick a network/chain "of" that project. Right now, doing this requires that I manually scrub and enrich the chains.json data, which kind of betrays the principle of having this data all already available and fetchable in machine-readable form.

* Theoretically, this is what `networkId` _should_ mean. But that's a lost cause — because of all the pre-CHAINID chains that use distinct `networkId`s despite being part of the same project, `networkId` is basically meaningless at this point, except as machine-readable data to talk to some very old node software.

* Grouping by `chainName` doesn't really work (despite this seeming to be the purpose of the `chainName` field?) as there are separate projects that reuse a "parent" project's `chainName`, e.g. https://www.elastos.org/ and https://primusmoney.com both having a `chainName` of "ETH" despite not having any affiliation with Ethereum. (They're only "Ethereum" to the degree that they run on the same node software, as all EIP155 chains do.)

* Grouping by `infoUrl` _almost_ works for this! but there are exceptions, e.g. Görli having its own separate `infoUrl` instead of pointing at https://ethereum.org.

What _does_ ~basically work, is parsing the `name` field and dropping the words `Testnet`/`Mainnet` and anything that comes after them.

IMHO, it'd be very helpful if there was a field in each chain that effectively contained the "first part" of what the `name` field contains. In other words, a `projectName`. Unlike `chainName`, it'd be human-readable. Also unlike `chainName`, it'd actually work for grouping :)

Some additional thoughts:

* The "other part" of the `name` field could be put into its own field as well, maybe something like `componentName` or `serviceName`. Seemingly right now `networkName` is being used as a slug-ified representation of this information, but it'd be helpful to be able to get it in human-readable form. (Also, there's nothing _forcing_ contributors to use `networkName` this way, so it has exceptions in it as well, e.g. chain-211 Freight Trust Network having a networkName of `"freight & trade network"`. That's not even a slug!)

* The resulting projects data would be somewhat repetitive and hard to maintain. It might be easier to normalize it—i.e. break these fields out into files in a separate directory `_data/projects`, assigning each project its own (arbitrary) foreign-key sequential ID number, and updating the chains in `_data/chains` to reference the project they belong to by its ID. This file could contain:
* a human-readable `name`
* a `shortName` or `slug`
* an `infoUrl` for the project itself
* potentially, the chainId for the "primary" or "production" chain that the project's community's efforts are focused toward
* potentially, a projectId that this project is a "forkOf" (e.g. in the case of Ethereum Classic)
* potentially, a projectId for a "parent" or "umbrella" project, if this project _isn't_ a fork (= no difference in community membership), but _is_ a set of networks that both "belong to" a parent project while also being their own thing (as e.g. the ETH2.0 networks are to the greater ETH community/ecosystem.)