Policy for user parameter and flag names

[DraTeots]

Currently there is no style for plugins parameters which needs to be fixed. For reference, each unit may create its own parameters, these parameters can be changed without software recompilation like

-Pparameter=value

Parameter name could be of any symbols. The only existing policy right now, that unit name (plugin/factory/processor) and parameter should be separated by ":". The separation is purely a policy. So the parameter names are like:

-Pjana:debug_plugin_loading=1

Example. We have lots of "SiliconTrackerDigi" factories with different tags and that require different input parameters (that is the goal). And currently we went a way of creating tags and wire factories by tags. Thus parameter naming policy should be something like

<base>[separator]<tag>[separator]<parameter>
SiliconTrackerDigi-BarrelTrackerRawHit:TimeResolution=10

@nathanwbrei proposed continue using ":" as a separator like this:

<base>:<tag>:<parameter>
#or if tag is absent
<base>:<parameter>

Thus if you see

-PAbra:Cadabra

You can guess that Cadabra is a parameter. While if you see

-PAbra:Cadabra:Boom

You understand that Cadabra is a tag.

Example of real names:

SiliconTrackerDigi:BarrelTrackerRawHit:TimeResolution=10
TrackerHitReconstruction:BarrelTrackerHit:LogLevel=trace

This required not only for readability but for better python API helpers

[DraTeots]

[At the EPIC Developers meeting 09/06/2022] it was suggested that

1. Using first detector name or plugin name would optimize code/parameters search being from global scope to local scope
2. Use detector abbreviations if possible

<detector/plugin_name>:<algorithm>:parameter=value
<plugin>:<algorithm>:parameter=value
<plugin>:parameter=value

Thus the correct naming examples are:

BVTX:SiliconTrackerDigi:TimeResolution=10
BVTX:TrackerHitReco:LogLevel=trace

[DraTeots]

Now the next questions:

1. Should all flags of the application correspond to CamelCase naming convention. So we have some consistency (see #119)
2. Should service parameters be in some namespace. E.g. global log level:

# (1) logging - plugin name with logging service
--Plogging:LogLevel         

# (2) just a flag as it is global
--PLogLevel                      

# (3) emphasizing that this is eicrecon global parameter
--Peicrecon:LogLevel        

[faustus123]

I believe the parameter names are currently treated as case-insensitive. That doesn't really say anything about the policy we should have. Just a note.

I think given the other existing policies (https://github.com/eic/EICrecon/blob/main/CONTRIBUTING.md) it would be appropriate to use snake_case for the config parameters.

Re: service parameters: I would vote for your first option. Yes, it is a little more verbose than option 2, but makes all logging options list nicely together. It also could be compacted to something like -Plog:level (where "log" is the actual name of the plugin I think). I would not be in favor of option 3 as it makes names more verbose and will be largely redundant.

Once decided, this should be added to the https://github.com/eic/EICrecon/blob/main/CONTRIBUTING.md document.