these methods are now called `decode_from_pdu()` and are the template
for all other objects which can be decoded (i.e., DOPs and
parameters): they take a `DecodeState` object as their lone argument
and return the decoded physical value. Note that these methods are
supposed to change the passed `DecodeState` object so that it is set
up to decode the next object after calling `decode_from_pdu()`.

This reduces the mental load required because before this, parameters,
diag coded types, and DOPs all used the same name for functions which
do similar but slightly different things...

Signed-off-by: Andreas Lauser <[email protected]>
Signed-off-by: Alexander Walz <[email protected]>

…eState`

if no bit position is specified/applicable, decoding continues at
first bit of the byte pointed to by `cursor_position`

Signed-off-by: Andreas Lauser <[email protected]>
Signed-off-by: Alexander Walz <[email protected]>

this should make it clear what kind of position is meant.

thanks to [at]kayoub5 for the suggestion.

Signed-off-by: Andreas Lauser <[email protected]>
Signed-off-by: Alexander Walz <[email protected]>

if something went wrong while loading a CLI tool, the backtrace can be
accessed via `odxtools $TOOL --help`.

Signed-off-by: Andreas Lauser <[email protected]>
Signed-off-by: Alexander Walz <[email protected]>

rather "work" (mind the quotes): If pyinquirer is working and this was
called "bare metal" (i.e., not via `pytest`), the `browse` tool
stopped to ask the user for input. Since this is undesireable for a
unit test, we now mock `sys.stdout.isatty()` to always return `False`.

Signed-off-by: Andreas Lauser <[email protected]>
Signed-off-by: Alexander Walz <[email protected]>

i.e., it is now always an integer, never `None`. This looses us the
ability of distinguishing between "no bit position defined" and "bit
position set to 0" in the decoding machinery, but this is not too
relevant as the ODX spec says that, the bit position ought to be
assumed 0 if it is not defined and policing if it is allowed to be
defined or not ought not should not be part of the decoding logic.

thanks to [at]kayoub5 for his persistence!

Signed-off-by: Andreas Lauser <[email protected]>
Signed-off-by: Alexander Walz <[email protected]>

It seems like PyInquirer does not work more often than not (e.g.,
importing the module fails). Since InquirerPy describes itself as `a
re-implementation of the PyInquirer project, with bug fixes of known
issues, new prompts, backward compatible APIs as well as more
customisation options.`, let's use it instead.

Signed-off-by: Andreas Lauser <[email protected]>
Signed-off-by: Alexander Walz <[email protected]>