fix some weak symbols in vendor device code

[mucki-at]

The way TU_ATTR_WEAK (weak symbols for linking) in this library is problematic and inconsistent. Weak symbols have two usages:

1. Mark symbols as optional. If no implementation is found during linking the function pointer will be null, which can be checked.
2. Allow multiple definitions. A weak default implementation in the library can be overridden by a strong definition of the user.

To use option 1, the declaration (in the header) should be marked weak, so the compiler knows that the symbol is entirely optional. To use option 2, the declaration must not be marked weak, so the compiler knows that an implementation must be provided, but the library can provide a default implementation (marked weak in the implementation) so that the user can override.

Option 1 is only feasible if the number of implementations is either 0 or 1. Since all implementations are weak, the linker will pick an implementation at random during link time, so there is no control which version will end up in the final program if there are multiple.

Option 2 provides automatic safety against multiple strong definitions (a link error will result). The linker will always pick the strong implementation if it exists, otherwise a random weak one.

In the library some callbacks are using Option 1, and some are using Option 2. Even more unfortunate the tud_vendor_control_xfer_cb uses Option 1 and already provides a definition in the webusb code.

This patch does not fully address the issue, since this is a library design issue and requires choices only the maintainer can make, however it fixes:

• tud_vendor_control_xfer_cb - webusb code will no longer hide user code
• tud_vendor_rx_cb - a default implementation is provided, but usage inside the library will no longer conflict with user overrides
• tud_vendor_tx_cb - ditto

my recommendation would be to either remove all weak annotations from headers and only use them in the implementations (tinyusb style), or expose completely new symbols which do not conflict with tinyusb names and avoid problems like only one vendor class callback when actually multiple might be needed.

[mucki-at]

Ok, tud_vendor_rx_cb were also touched in master which was hard to figure out because I cannot test your builds locally before submitting a PR, but it seems fixed now. The change is even smaller now :)

[mucki-at]

Spoke too soon. But I totally do not understand these new errors. Somehow the sample (which is not modified) conflicts with code in Arduino core which are not even part of this library? Can someone explain how you guys are building this, because I can't even see these files.