Run interface shells around build, dev

[jasonkuhrt]

Perceived Problem

• docs: add migration guide for nexus-plugin-prisma graphql-nexus/nexus#817
• in order to allow plugin settings to have non-serializable data (functions, namely) we need to reflect on used plugins in the same process as where those plugins will be used.
• The problem is that reflecting on used plugins in the cli process exposes the cli process to problems in the app, namely:
  1. process.exit
  2. infinite loops
• If either of these things happen, from a Nexus user point of view, when they run nexus dev or nexus build, they will get no feedback, seeing their command abruptly exit or hang forever (not even responding to sigterm if the infinite loop is synchronous)

Ideas / Proposed Solution(s)

• After discussing with @Weakky we concluded that the cli process can run dev/build in a fork

• We can visualize the process architecture:

   Process Trees
  
   Build CLI 				(UC|IL)
   	|--> Build  		(UE) 	^UE|UC|IL*
   		|--> Reflection 	 	^UE|UC|IL
  
   Dev CLI 				(UC|IL)
   	|--> Dev 			(UE) 	^UE|UC|IL*
   		|--> Reflection 		^UE|UC|IL
   		|--> App Runner 		^UE|UC|IL
  
  
       ^ = can happen
   (...) = can capture
      UE = Unexpected Error (throw)
      UC = Unexpected Crash (process.exit)
      IL = Infinite Loop
  
  
   * plugin reflection runs here, hence it makes possible UE|UC|IL
  

• the cli process would do as little work as possible

• the cli process job would be to monitor for health of the build/dev process

• the cli process, upon detecting UC or IL would let the user know gracefully.

  • just exit with a clear message?
  • offer prompt to try again (at their command, since they need to make some kind of change to their app to fix the issue)