Fix lack of update in edit mode with Cycles

Use engine from context/render in more places

Fix engine context in Cycles

Store engine_name in render struct and use it for render preview

Workspace/Engine: Create BKE_render_* calls equivalent to BKE_scene_*

Fix UI compatibility to use context.engine

Use workspace engine for draw manager "render preview"

Note: When saving .blend files, thumbnails are saved too.
In this particular case we are not doing a "scene render", but we also
don't have any UI (so no workspace).

So we need to consider workspace to be NULL in the render_engine_get()
function.

Use workspace -> engine in the viewport

Not yet for OpenGL render.

Collection Panel: Get mode from workspace

Those overrides will change, and this panel may not exist in the future.
But meanwhile let's make things work as tey were supposed to.

Context: Expose "engine" for Python and add BKE_render_engine_get()

Expose scene > engine in the UI (render panel)

Use workspace -> engine in the opengl render

Pass workspace for space listeners

Space Image needs this to get active layer to get active object.

Workspace: "use_scene_settings" flag

This option determine whether we get the engine, layer and render settings
from the workspace or from the scene.

It is useful to allow for quick preview of the final render (F12) while in
a workspace,

Properties Editor: Add Workspace and organize context path

We now have the properties of:

Scene, Scene > Layer, Scene > World, Workspace

[Scene | Workspace] > Render Layer > Object
[Scene | Workspace] > Render Layer > Object > Data
(...)

We use Scene or Workspace depending on workspace.use_scene_settings.

Also, we no longer expose the object in the collection context.
Since this should go away (and at the very least we should get the mode
from the workspace).

Workspace: Add (render) engines

We still need to change the viewport so it uses this instead of scene.rd.engine.

Workspace: SETLOOPER should get render layer from workspace

Right now we are still passing NULL instead of the workspace in most of
those cases. That shouldn't matter much since this will simply bring
back the previous behaviour.

Also, most of those calls (gpu_material.c, view3d_draw_legacy.c,
render_internal.c) are from deprecated areas of Blender anyways.

The areas that will need to be addressed are:
* physics (collision.c)
* particles (pointcache.c)
* sound (sound.c)

And of course:
* game engine (BL_BlenderDataCoversion.cpp)

It's not clear to me, however, why some of those areas are using the
SET_LOOPER in the first place. SET_LOOPER acts on top of bases so we
want to iterate over the SceneLayer objects, not all of scene ones.

However in some cases it seems that the original design was expecting to
loop over all the objects (+ the set objects).