Adding DLL export/import tags to generated public upb API

[dawidcha]

I have been collaborating with the grpc developers to make it possible to build that library as a Windows DLL - a couple of PRs were already merged, more like https://github.com/grpc/grpc/pull/34345 are pending.

The grpc library incorporates some upb-generated, and upbdefs-generated code into grpc.dll, which is referenced by other code that consumes the library. Since this is now a DLL, that code doesn't know how to link to these generated symbols because they are not annotated with __declspec(dllimport).

This PR aims to fix that by introducing a parameter 'dllexport_tag' to the upb and upbdefs plugins. That parameter should be a string e.g. MYAPP_DLL and when set, the extern symbols are annotated with a macro with that name. This can either be set externally to __declspec(dllimport) or, as is usual practice, when compiling code into a DLL, the macro <dllexport_tag>_EXPORT (i.e. MYAPP_DLL_EXPORT) is defined, and when consuming the DLL <dllexport_tag>_IMPORT is defined if neither are defined then the MYAPP_DLL macro becomes empty string which is what you want for building a static library.

This is a continuation of https://github.com/protocolbuffers/protobuf/pull/14230

Fixes: https://github.com/protocolbuffers/protobuf/issues/14255

[google-cla[bot]]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[veblush]

LGTM

[hlopko]

@dawidcha could you resolve the comment from @haberman? We'll then look into the internl failure (which seems to be an issue with some pre-generated files that just need to be regenerated together with your PR).

[dawidcha]

Looks like the CLA blocker is finally unblocked I've rebased and I think we should be ready to take this over the line

[h-vetinari]

@dawidcha could you resolve the comment from @haberman?

That still seems to be open, but assuming this is not that hard to fix, it'd be awesome if this could still make v26.0! 🙃

It's causing issues in grpc, for example.