Implement J1939 protocol in the CAN service binding

Close for HH RC2

Subtasks has been created to follow the works about that:

https://lf-automotivelinux.atlassian.net/browse/SPEC-2497#icft=SPEC-2497

https://lf-automotivelinux.atlassian.net/browse/SPEC-2498#icft=SPEC-2498

Finally, after a discussion with Jan-Simon, we agreed on two things:

• for HH, let's fix the few things in current reviews and add build-time detection through CMake (no explicit flag in recipes)

• we open a new ticket to follow-up the development with next tasks: add support for J1939 in 4.14 and 4.19 kernels and then add runtime detection in binding. That will be pushed on master after HH release (expected landing: august or september)

My point is to follow 'KISS' also for the distribution and usage side - and not just at the code level where we for sure can live with a build time switch quite well.

Of course it is simpler as a build time option. I agree.

 But OTOH we can make it simpler to apply if we do only need to enable the kernel flag and not flip more switches at compilation time, or per board, or per use-case.

Yes, if we add auto-detection, there might be the wish for a flag to disable J1939 completely or enforce its use at runtime (aka fail if not present) then.

We can satisfy the engineered use-cases very well through this - but also make it 'just work' w/o us hunting all cases.

The big benefit is still that we :

• do not need any pre-{processing/knowledge/extra work} - aka "does the board now have J1939?" or "did you _build with flag XYZ"

• or post-{processing} - aka "Bugreport: hey, did you enable this flag as well?", "Did you install the correctly-built service?"

Above is basically user / maintainer benefits.

For the distro this means as well:

• no duplicate service builds (per board or per use-case)

TLDR: I think this causes a rat-tail of extra stuff to do and I'm sure we can do better.

J1939 as a build time option is ok. In a real car this is not something that comes and goes. The OEM either uses it or they do not and that is well known in advance.