Rhfogh develop Adapt to newest paramsgui changes (from jbf)

[rhfogh]

This PR (and the companion PR in mxcubeqt) means that the qt UI now works with the latest mxcubecore changes (and includes some minor clean-ups and fixes).

A couple of points need consideration, for the changes to the paramsgui:

• The entries for new wf_type field has been changed as it did not work with the system; this raises a general point:
  As the system works, the schema["properties"] contains an entry for every data field, but none for pure container fields.
  The ui_schema, on the other hand, contains only entries for displayed fields, as a nested structure of containers and contents.
  It is therefore not possible to add parameters in the ui_schema for fields that are not displayed, since these entries do not appear in the nested container structure. Also the wf_type field, as entered, was displayed on top of the main container field, proving that all displayed fields should be inside a container. As the system works after this PR, all fields that do not appear in the nested hierarchy of containers (including wf_type) are automatically treated as hidden and read_only, but can be accessed through the general dictionary of parameter values.
  If this is problematic for the web implementation we need to consider alternatives together.

  I should add that the organisation of ui_schema could be changed if we have a good reason for wanting to do so, but this is the way it is at the moment and that was the quickest way of making the system functional.

• I have replaced the signal sent from the GUI with a call to a function on the mxcubecore side (which then in turn emits the signal). To be generic this function had to be put on a fairly general object on the mxcubecore side. I opted for the Beamline object as a neutral location. The function, 'emit', is almost identical to the emit function in HardwareObjectMixin, but Beamline is not a subclass of this class, as the beamline, while yml-configured, is not a hardware object. 1) I am not sure of the exact considerations with what should be imported from core to GUI - might we want a different location? 2) it would be neater if we could avoid the semi-duplication of the emit function - does anyone have an idea?

[jbflo]

@rhfogh I think we should remove wf_type field
Sorry for Adding it, but since we decided to create a specific component for display gphl form
it is no longer needed. and should be removed.

[rhfogh]

No problem - it will take a few experiments before we settle all of this. I'll just remove it again ASAP.

[rhfogh]

The wf_type field has now been removed