Default network for different compiled bins is still defaulting to Esme

[brianp]

Problem

With the introduction of network based feature gating I attempted to apply a change to set different default networks for the different bin compliations.

This change did not have the desired effect and the NextNet binary still defaults to Esme. This is very confusing because a user would be immediately met with an error message informing them Esme is not a valid network choice for the NextNet binary.

The appropriate default was not used because the tari_common crate is not utilizing a build.rs, and in turn not utilizing the tari-feature gating configuration.

Solution

Introduce the tari-feature build settings to tari common. This will also introduce a cyclic dependency so it's more likely that we should move tari-features directly into tari-common.

[brianp]

A little more thinking on this and moving tari-features into common doesn't work because we're saying common needs to be tari-feature aware.

I think what we need to do instead, is free tari-features of any outside dependency. It's only dep is tari-common, and it only uses the Network. I think we could probably address this as the problem.