fix: ensure ember-data works properly

[runspired]

• enable local builds of ember-data to be used
• fixes for ember-data docs not appearing properly

Docs Generation Changes

resolves #117
partially resolves #118 by enabling work arounds

note, with this change you must explicitly opt-in to install and build of docs locally.

yarn gen --project ember --version 4.12.0 --build --install

If you don't opt in you will get whatever docs build was last built in that project, which for local purposes like this is typically preferred anyway.

Docs Parsing Changes

Updated Parser

Updated the parser to resolve several issues with EmberData docs not being correctly parsed. I've manually reviewed all EmberData documentation and this has no ill-effects. We should also review the Ember documentation.

• updated highlight.js from ^10.4.1 to ^11.7.0
• updated marked from ^0.7.0 to ^4.3.0

Fixed Async Issues

• the generate-local command now directly invokes main vs running yarn via execa. This ensures that crashes are correctly reported, they weren't before.
• various promise spaghetti has been refactored to async/await and a few things that could race before were made linear (the for ... of change). This generally enabled errors to surface instead of getting lost. We also seem to always complete the docs build now, before if an error occurred we would see "success" but not actual have an updated asset or see an error.

Fixed Bug

There was a bug in which documentation with an id longer than 50 would not be saved into the json-docs.

ember-jsonapi-docs/lib/save-document.js

Lines 21 to 23 in d25d94a

	if (document.data.id.length > 50) {
	// wtf ember 1.0 docs??
	return resolve()

This led to the module @ember-data/experimental-preview-types not being built properly. I've utilized the code comment to improve the heuristic to capture whatever case this was originally here for (sounds like no one knows?) so that EmberData's docs will correctly build.

[jenweber]

Jared and I tested this locally for a couple Ember versions, and it seems good to go!

@runspired we ran into one issue, which is that the data repo has very specific pnpm requirements. Could that be changed to allow the specified version or any later version within the major, i.e. >= ^8.1.0 or >= ~8.1.0? Currently, it seems to require exactly the version down to the patch digit. Our docs release process has quite a few hurdles in it, so if we can reduce this one, that will be helpful.

Note to learning team contributors: This change breaks our release tool due to the pnpm change above and the install flag, but we were already usually running these releases manually lately. One solution is that we could make a script for package.json that handles these 2 issues, and use the new command in the release tool instead of what we have in there currently.