Add Entity descriptor for beamline-level object

[DiamondJoseph]

With the aim of making a beamline ec repository document the capabilities and state of a beamline.

A Beamline is composed of multiple levels:

Physical components (motors, detectors, other hardware): how well do these map to Resource entities? With potential dependency chains to explain device interactions (e.g. temperature controller A requires pump B, or stage C is a dependency of detector D that is mounted to it?). Resources only allow one string of spec.type, does this allow a useful level of device granularity when defining beamline capabilities?

Can a device be suitably defined by some agreed upon standardised fields, something like this?

apiVersion: backstage.io/v1alpha1
kind: Resource
metadata:
  name: stage-y
  namespace: p45  # Prevents name having to be globally unique
  description: Make, model
  tags:  # Some useful common definition of hardware capabilities? Or as labels, or as annotations?
    - axis_physical
    - axis_vertical
    - axis_limited  # Provides axis_max, axis_min labels?
  labels:  # Labels are 
    axis_max: xxx
    axis_min: xxx
    axis_precision: xxx
  annotations:  # How Panda TTLOUT are wired to device external triggers?
    input.p45.panda1.ttlout: 1
    input.p45.panda2.ttlout: 1
spec:
  type: axis
  dependsOn:
    - resource:p45/stage-x  # mounted on top?
  owner: p45  # Is owner p45 or controls engineer or?
#  system:  # Define a Controls system for the hardware, IOCS?

IOCs that control the physical components- are these Components, with dependencies on the physical components (if those are Resources, these can be Components fairly simply)

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: stage-y
  namespace: p45
  description: IOC controlling stage-y Resource
spec:
  type: IOC
  lifecycle: production
  owner: user:JoeBloggs # Controls engineer for p45?
#  system: Controls  # Define a Controls system for the hardware, IOCS?
  dependsOn:
    - resource:p45/stage-y
   providesApis:
    -  EPICS-CA # Define how to talk to the device? 
    - # Can we generate an API from pvinfo/PVI/cainfo?

Central or Beamline services (from acquisition, analysis or controls): Components, which may also contribute to a System, such as the Athena system.

Does a Beamline consist of a System, or only the components that belong to the system that are enabled for it?
A Component can only be part of one System, so cannot readily have a Beamline defined as a System (components exist on multiple beamlines, and may already be a part of a System).

Suggested schema for Beamline-level object

apiVersion: # Diamond apiVersion string
kind: Beamline
metadata:
  name: p45
  namespace: p45  # may have multiple beamlines in same namespace if share resources
  description: P45 Test rig, configured with x, y, theta stage, det, diff cameras, white light and monochromatic laser.......
spec:
  lifecycle: production
  owner: user:JoeBloggs # Multiple responsible persons?
services: 
- p45-specific-service
- stage-y  # ioc
centralServices:
- central-service-being-made-use-of

[DiamondJoseph]

Docs on how to add a new Kind of Entity:
https://backstage.io/docs/features/software-catalog/extending-the-model#adding-a-new-kind
https://backstage.io/docs/features/software-catalog/extending-the-model#implementing-custom-model-extensions