C++ Engine refactor

[mindhells]

No (intended) behavior change in this PR, perhaps some minor improvements (loops, temp vars, repeated/unneeded operations).

• New entity "calcoptions" to avoid carrying all its properties as constructor parameters for underneath classes.
• Introduced the use of unique_ptr as well as reviewed some class initializations to simplify.
• remove some unused/unreachable code.
• rename and reorganize members for some classes to clarify public interfaces and the use of private members.
• introduced some std utilities like vector.
• started working towards SOLID principles (specially "single responsibility")
• update old fashion idioms like c-style type casting
• ...

* for this PR I want to keep the current fract4dc interface. This impedes some decoupling (at least without introducing more complexity on the python extension implementation). For example: STFractWorker is a friend class of fractFunc. That's an already identified code smell, and you can can see how python tests using fw_create need to, without apparent reason, to create a fractFunc when they only want to test the worker.

[edyoung]

I can't honestly remember why that would be 🤔

[mindhells]

I think it's because the alpha it's not saved in the image buffer:

rgba_t image::get(int x, int y) const
{
    char *start = buffer + x * 3 + y * m_Xres * 3;
    //assert(start  + 2 - buffer <= bytes());
    rgba_t pixel;
    pixel.r = start[RED];
    pixel.g = start[GREEN];
    pixel.b = start[BLUE];
    pixel.a = 0;
    return pixel;
}

[edyoung]

looks good overall, thanks. Calcoptions seems a nice improvement. I've never personally found the m_ convention for member variables all that useful but I don't mind having it.

[mindhells]

I've rebased this branch with master. I plan to do further refactor but since you've already reviewed most of it... feel free to merge.
About the m_convention: I think it's ugly but helpful when looking at large member functions. That being said you can rely on the IDE for that kind of help or maybe a better-looking convention/style. If you have any particular preferences there I'd be glad to follow them

Right now I'm trying to get rid of the "friend" coupling between fractFunc and STFractWorker. I'm wondering about the best strategy for them to share the information they're sharing now and, if possible, reduce it.
Seems fractFunc is holding a lot of responsibilities:

• calculating 4D geometry
• reporting calculation progress and events through a site
• high level stats-based predictions (auto-deepen and auto-tolerance): this updates the calcoptions
• manage workers (request for work to be done, flush pending work, get stats from them)
  On the other hand the STFractWorker depends on the geometry, the calcoptions (that might be updated by fractFunc), ...
  One of the benefits I'd like to provide with this is to ease tasks like introducing arbitrary precision, or any other complex enhancements on the roadmap.

[mindhells]

Hey guys, for what it's worth, I'm finished with this PR. I didn't do much since your review except for rebasing with master.
On the other hand I'm working on decoupling fractFunct and STFractWorker (friend classes for the time being). If you are curious how it's going check 8cd17f6 (feel free to leave any comments, I'd appreciate them). PR will come after this PR, since it's based on its status.

[edyoung]

Thanks :-)