chore(build): add types to errors in build

[JGAntunes]

🎉 Thanks for submitting a pull request! 🎉

Summary

This is related with COM-129 - https://linear.app/netlify/issue/COM-129/expose-location-information-for-errors-in-netlifybuild - where we want to capture particular error data in our traces. We continuously struggle to understand our error types and make sense of what properties we have in place when going through the many mutations they go through. This is a first stab at adding types to our errors in @netlify/build. There's almost certainly things we can improve but the idea here is to start somewhere.

---

For us to review and ship your PR efficiently, please perform the following steps:

• Open a bug/issue before writing your code 🧑‍💻. This ensures
  we can discuss the changes and get feedback from everyone that should be involved. If you`re fixing a typo or
  something that`s on fire 🔥 (e.g. incident related), you can skip this step.
• Read the contribution guidelines 📖. This ensures
  your code follows our style guide and passes our tests.
• Update or add tests (if any source code was changed or added) 🧪
• Update or add documentation (if features were changed or added) 📝
• Make sure the status checks below are successful ✅

A picture of a cute animal (not mandatory, but encouraged)

[JGAntunes]

This came from analysing:

• build/packages/build/src/error/parse/location.js

  Lines 3 to 61 in 481a42e

  	// Retrieve an error's location to print in logs.
  	// Each error type has its own logic (or none if there's no location to print).
  	export const getLocationInfo = function ({ stack, location, locationType }) {
  	// No location to print
  	if (locationType === undefined && stack === undefined) {
  	return
  	}
  	// The location is only the stack trace
  	if (locationType === undefined) {
  	return stack
  	}
  	const locationString = LOCATIONS[locationType](location)
  	return [locationString, stack].filter(Boolean).join('\n')
  	}
  	const getBuildCommandLocation = function ({ buildCommand, buildCommandOrigin }) {
  	const description = getBuildCommandDescription(buildCommandOrigin)
  	return `In ${description}:
  	${buildCommand}`
  	}
  	const getFunctionsBundlingLocation = function ({ functionName, functionType }) {
  	if (functionType === 'edge') {
  	return 'While bundling edge function'
  	}
  	return `While bundling function "${functionName}"`
  	}
  	const getCoreStepLocation = function ({ coreStepName }) {
  	return `During ${coreStepName}`
  	}
  	const getBuildFailLocation = function ({ event, packageName, loadedFrom, origin }) {
  	const eventMessage = getEventMessage(event)
  	const pluginOrigin = getPluginOrigin(loadedFrom, origin)
  	return `${eventMessage} "${packageName}" ${pluginOrigin}`
  	}
  	const getEventMessage = function (event) {
  	if (event === 'load') {
  	return `While loading`
  	}
  	return `In "${event}" event in`
  	}
  	const getApiLocation = function ({ endpoint, parameters }) {
  	return `While calling the Netlify API endpoint '${endpoint}' with:\n${JSON.stringify(parameters, null, 2)}`
  	}
  	const LOCATIONS = {
  	buildCommand: getBuildCommandLocation,
  	functionsBundling: getFunctionsBundlingLocation,
  	coreStep: getCoreStepLocation,
  	buildFail: getBuildFailLocation,
  	api: getApiLocation,

[JGAntunes]

I'm guessing there's probably better ways to deal with this in the future if we break down this large object and create separate types for these 🤔

[kitop]

Looks good to me, but would love the eyes of somebody more familiar with the TS type system.

[eduardoboucas]

LGTM