Support using different toolchain versions in one Nerves project

[fhunleth]

Currently each toolchain is specified as a hex dependency in the Nerves system. It's important that the toolchain that compiled the Nerves system is compatible with the one being used to compile NIFs and ports in a Nerves project. For example, it would be bad if a Nerves user got a toolchain update that updated the C runtime libraries without the corresponding Nerves system update. That could result in a new function being called that wasn't in the shared libraries included with the system and would cause code to break at runtime.

The way this is currently solved is by using mix dependencies to ensure toolchain versions match and works well most of the time.

The problem comes when you have a multi-target Nerves project. All Nerves systems in that project need to be updated in unison when the toolchain changes. This is because mix only allows one version of the dependency in a project at a time. In theory, the Nerves project should be fine since the Mix target specs for the dependencies ensure this constraint. However Elixir doesn't have a means for supporting this and it may, in fact, cause more confusion if it were added since dependency resolution already is a hard problem.

One solution is to create a new hex package for every major version of GCC. That way a Nerves system that would work better with GCC 14 doesn't need to wait for a GCC 13 bug fix for a different Nerves system. See #145 for an example that is causing this to happen. This also would help improve the situation where if you have a project that pulls Nerves systems from multiple maintainers, you don't have to wait for all of the maintainers to publish an update before upgrading yourself. This situation also requires improvements to the Nerves system, but decoupling toolchains is needed for it too.

The downside of making a hex package per GCC version is that it really adds a lot of hex packages. This looks like an inelegant solution when you first see it, but it's unclear what would be significantly better. It also looks hard to maintain unless this project gets updated to generating mix toolchain projects via scripts.