Fix FES errors, parameter data omitting classes

[davepagurek]

Changes

Parameter validation was failing when createCanvas(200, 200) was called in npm run dev. It turns out there were some FES issues introduced with the most recent FES PR, partially from other changes that have happened since it was started.

Fixed constant lookups

Previously, a regex would be used to find constants, and it would grab the values out of the constants file. However, the regex didn't handle P2D since it has a number in it, and it didn't handle RADIANS which comes from another file.

Now, it just checks for any key in p5 that starts with a capital letter and then is followed by capital letters or numbers.

Fixed missing p5 classes

Previously, it would only handle type references to p5 classes, e.g. p5.Color, by checking for their presence in the parameterData.json info. However, classes will only show up there if they have methods. (A bunch were also missing due to the reasons in the next paragraph.) I've updated it to look up p5 classes again by checking for functions in p5.prototype that start with a capital and are not already a constant.

Fixed missing class methods in parameterData.json

The largest change was in how we export classes. Previously, it looked like this:

/**
 * Description here
 */
p5.Framebuffer = class Framebuffer {
  // ...
}

Now, it looks like this:

class Framebuffer {
  // ...
}

function framebuffer(p5, fn) {
  /**
   * @class p5.Framebuffer
   * Description here
   */
  p5.Framebuffer = Framebuffer;
}

Earlier, everything just worked, and methods on the exported class would be correctly parsed by Documentation.js. Now, Documentation.js parses all methods on the class as belonging to Framebuffer, not p5.Framebuffer, which doesn't have exported docs, which caused them to not get used in validation.

To fix this, I'm now adding p5. to all class memberships in convert.js. @diyaayay, I suspect you'll need to do the same in the TypeScript type generator, maybe we can try to factor out some of these common helpers and use them in both scripts to ensure some consistency?

Added tuple type support

paletteLerp previously had a non-functional special case in the code. I noticed it wasn't even present in dev-2.0 yet, so I added it in and added actual support for tuple types in param signatures.

[diyaayay]

I see some helpers common in both scripts. We can export them and use the common helpers. I'll add the relevant changes in my PR.