Data rate fixes

[spiiroin]

[nodebase] Use closest supported data rate. Fixes JB#60314

What kinds of data rates are available for sensors varies from one
device to another. Having sensorfwd completely ignore out of bounds
data rate requests creates a situation where applications can work in
completely different ways on different devices.

Instead of rejecting out of bounds data requests, choose closest
supported data rate.

[sensorfw] Drop evaluateIntervalRequests overloading. JB#60314

NodeBase::evaluateIntervalRequests is virtual method that about every
derived class overrides - with almost identical copy paste code.

The only difference between these variants is how placeholder zero
interval is handled. Base behavior seems to want to treat it as "as
fast as possible" while others take it to mean "use the defaults."

When intervals were defined in millisecond granularity, using zero
might have had some use for reaching > 1kHz data rates. Now that
microseconds are used, the boundary for expressable data rates has
moved to >1MHz level and dual role for zero value is less useful.

Change NodeBase behavior to match what the multitude of derived
classes used to do and drop all the now unnecessary copy-paste
methods.

[hybrisadaptor] Fix setDelay() return value

If data rate adjustment is skipped because data rate did not change,
setDelay() returns failure - which then causes journal spamming and
other hiccups.

Return success if data rate adjustment is skipped on purpose.

[sensorfw] Handle intervals in microsecond granularity. Fixes JB#60313

Sample intervals within sensorfwd are handled in microsecond granularity
and converted to appropriate units when dealing with external interfaces
such as D-Bus, Android hal, or sysfs control files.

[sensorfw] Add setDataRate() D-Bus method. JB#60417

Using integer millisecond sampling interval is problematic for
specifying high acquisition rates as it limits choice to
1000, 500, 333, 250, 200, ... Hz and thus rules out e.g. 400 Hz
altogether.

Use microsecond granularity interval time internally and provide new
setDataRate() method that takes double precision floating point
Hertz parameter - while retaining the already existing setInterval()
method for the sake of backwards compatibility.

Note that this only deals with D-Bus interface level. Further changes
in sensorfw side are needed to actually support e.g. 400 Hz data rates.

[sensorfw] Explicitly indicate interval time units. JB#60313

As a preparatory step for using different time units in D-Bus interface
and internally within sensorfw: use "_ms" suffix for all interval
arguments and member variables.

Also make affected classes follow m_variableName naming convention.

[sensorfw] Normalize setInterval() parameter order. Fixes JB#60301

The order of interval and session id parameters for setInterval() methods
varies within class hierarchy present in sensorfw.

Normalize situation so that when setInterval() method takes session id
parameter, it is always the first argument to pass - which aligns with
dbus interface.