Generate nuget package for System.Device.Gpio

[joperezr]

cc: @ericstj @safern

These changes will add the required targets in order to produce a package for System.Device.Gpio. For now, it will have the following layout:

ref/
  netstandard2.0/
    System.Device.Gpio.dll
runtimes/
  linux-x64/
    lib/
      netstandard2.0/
        System.Device.Gpio.dll
  win/
    lib/
      netstandard2.0/
        System.Device.Gpio.dll

We will also need to eventually add one more asset lib/netstandard2.0/SYstem.Device.Gpio.dll to be a turd assembly so that we do in fact support netstandard2.0

[raffaeler]

I love taking advantage of the reference assemblies to provide multiple implementations.
It would be even better if the nuget system allowed to take in input an additional discriminator to differentiate the physical device.

Imagine there are two devices (such as OrangePi or RasperryPi) supporting a different pull-up resistor configuration. Both can run Ubuntu, so I can't differentiate the GPIO library by RIDs.
Instead I would like to have a new discriminator, possibly a user-defined string specified in the csproj, that can be used by nuget to match the required library.
Probably it would be better to have the ability to specify multiple alternate discriminators that would trigger a "first-match" logic.

I would post this in the nuget repo, but it would be hard to explain as this example perfectly match on hardware libraries (but I have other non-hw scenarios in mind).

[joperezr]

For physical devices, like RaspberryPi or Hummingboards, what we are doing is that the Linux implementation contains those different drivers that are tied to different boards. We also have some default constructors that depending on the board you are running on, it will get you the driver that best applies, but this can only be done at runtime, so it can't be a NuGet feature.

[raffaeler]

@joperezr I get your point, but I still see a value in taking a different implementation depending on a value specified in the referencing project. This could avoid a lot of pre-processor directives in the final app.
Beyond the GPIO, where I agree you can level the differences at runtime, there are other hw peripherals that may be missing and would require a different strategy that would be a useless weight on other devices.

[safern]

We typically import this one at the beginning to respect the sdk convention in hierarchy

[joperezr]

The problem is that that one will import the arcade sdk, which will set the Version of the package, so I want to set Major and Minor version first.

[safern]

Are you planning on sharing a version across packages?

[joperezr]

this is to set the package version. It will also set the Assembly version for now but that is fine because I also want that to be 0.1.0.0. Once we ship a different version of assembly this will change.

[safern]

I thought you had to set a IncludeBuildOutput property and set it to false so that it doesn't include it in the package.

[joperezr]

That is set in the Directory.Build.props of this project. I wanted to move all the packaging related things over there, except for this property so that when we look at the project we know that this project will generate a package.