Move NXlens_em to base classes

[lukaspie]

This implements what was discussed in #1407 (comment). It moves NXlens_em from the contributed definitions to the base classes and adds it to NXsource as an renameable group. The difference between the NXlens_em from the contributed definitions and in base classes comes down to formatting, but no new terms have been added.

Note that NXlens_em itself is an extension of NXcomponent (which is meant as a basis for describing any components of an instrument). NXcomponent is also making use of NXcircuit (used for any sort of electronic circuit devices), so this is brought in here as well. These were originally to be discussed in #1424, but I think it's best to bring them in here.

[phyy-nx]

Comment from Telco:

• NXcomponent seems like a big change. And that many base classes should derive from it. The NIAC requests a survey of base classes to identify those which should and those which should not derive from NXcomponent. Examples include NXdetector which should, and NXdata which should not.
• As a corollary, adding NXcomponent as a new parent class to classes such as NXdetector, NXbeam, etc., would be a significant change, so move NXcomponent to a new PR, and make this one dependent on that new PR

Alternate proposal: instead of NXcomponent, add the necessary new fields to NXobject. This would imply that NXobject has NXfabrication and NXcircuit, but that's ok. Better to have more possibilities on NXobject than to add more base classes in general.

Reviewed in the NIAC: took a straw poll and it was almost evenly split between the above two options. This will need more discussion. @nexusformat/developers please chime in here! Thanks!

[lukaspie]

Comment from Telco:

• NXcomponent seems like a big change. And that many base classes should derive from it. The NIAC requests a survey of base classes to identify those which should and those which should not derive from NXcomponent. Examples include NXdetector which should, and NXdata which should not.
• As a corollary, adding NXcomponent as a new parent class to classes such as NXdetector, NXbeam, etc., would be a significant change, so move NXcomponent to a new PR, and make this one dependent on that new PR

Alternate proposal: instead of NXcomponent, add the necessary new fields to NXobject. This would imply that NXobject has NXfabrication and NXcircuit, but that's ok. Better to have more possibilities on NXobject than to add more base classes in general.

Reviewed in the NIAC: took a straw poll and it was almost evenly split between the above two options. This will need more discussion. @nexusformat/developers please chime in here! Thanks!

#1525 implements option 1 here and adds a list of all classes for which it would likely make sense to extend NXcomponent. This is more meant as an exploration/survey rather than a votable proposal.