Add custom face color calculation function

[InstrinsicAutomations]

• Optional custom face color calculation callback function.
• Fall-back to default (original) face color calculation function.
• Face class to hold face data and calculate a unit normal (cached).
• Made use of the vector math library functions and removed the hand-made functions.
• Moved the asserts in the previous PR to be next to the ones in the original code (in the constructor).
• Left an example how to use the face color calculation callback function.
• Provided 2 new screenshots: Fresnel (example.dart) and glass diffraction approximation.
• Updated readme.

New:

• Added new linter rules and applied all necessary changes to comply with linter.
• Replaced vector_math with vector_math_64 to avoid unnecessary casting. Similar issue.
  • Dart will turn those offsets into Float32 buffers at the end anyway for us.

[arnovanliere]

Could also do something like this: face = faceColorFunc?.call(face) ?? _defaultFaceColor(face);

[InstrinsicAutomations]

Didn't know about this! Will do.

[InstrinsicAutomations]

done

[arnovanliere]

I think it would be a bit nicer to extract these function parameters above this call so its a bit more readable

Suggested change

	Face face = Face(verticesToDraw[faceIdx[0] - 1],
	verticesToDraw[faceIdx[1] - 1], verticesToDraw[faceIdx[2] - 1]);
	final v1 = verticesToDraw[faceIdx[0] - 1];
	final v2 = verticesToDraw[faceIdx[1] - 1];
	final v3 = verticesToDraw[faceIdx[2] - 1];
	Face face = Face(v1, v2, v3);

[InstrinsicAutomations]

done

[arnovanliere]

I've also added a workflow to lint and analyze the code base. You should probably first merge that into your own branch so the workflow can run on this pull request as well. This is also necessary to resolve the merge conflicts.

[InstrinsicAutomations]

The only linter not addressed was the request to change explicit types to var. Correct me if I'm wrong but this is an out-dated variable type with Dart is it not? I'm ok with final variable_name = expression because at least the expression resolves to a type. But when there's no right-hand expression, being forced to use var is generally going to be unreadable.

[arnovanliere]

The two list initializations can be written like this

final List<Offset> offsets = [];
final List<Color> colors = [];

If you use a constructor, it is redundant to also provide a type for the variable, so

Face face = Face(...)

can be written like

var face = Face(...)

But as I was writing this, I read the style guide for the Flutter repo and this recommends to always explicitly type variables (as you were doing). If you can find the right combination of rules to enforce this style, go ahead and change them. I do honestly not really care for which code style is used, as long as it is consistent and a common set up in other Flutter projects