Create a metal_port datasource

[displague]

Introducing metal_port as a datasource, ahead of any refactoring to offer a metal_port resource (#12 (comment)) will give users the ability to work with ports that may be in use by appliances, connections, or devices. The attributes of this datasource will give us a head start on a metal_port resource.

This data source could offer device_id search fields in addition to id (port_id). Port name may also be a helpful search field.

For users looking to fetch the metal_device_network_type of a device, this would be possible by fetch the network type on each port and performing the same logic used by metal_device_network_type (this logic is not present in the EM API, this TF provider formulates it, like the EM Portal. This single device "network_type" does not fit the broad reality of port configurations across all EM device models.

Users can get to the device_id through the existing metal_vlan data source. Likewise, ports can be listed on the metal_device datasource. However, there is no TF way (that I know of now) to get the ports related to a VLAN (or vice-versa) today.

This resource should follow /ports/{id}. There may be other port attributes exposed in devices, connections, VLAN, or other resources, but my first inclination is to avoid including those in metal_ports. If we've omitted useful fields in those other resources, that are within a ports attribute, we should fill in the missing attributes in those resources.