If you work in .NET, you could take advantage of its mechanism of assembly loading.
In a nutshell, an assembly is typically loaded into memory when one if its types is first accessed. A type is first accessed when a method which contains a reference to that type begins to execute.
This means that you can have your assembly reference the ESRI.ArcGIS.Framework interop assembly even in pure ArcGIS Engine environment - as long as any methods which work with this assembly never execute. If they don't ever begin to execute, the CLR will not attempt to load the dependency.
This is well-defined behavior, meaning you can rely on it without worrying it will change between CLR releases.
If this is still not suitable for your scenario, there are other things you could do, such as define a simple interface for setting the current tool and use some kind of dependency injection/inversion of control. You'd have another two assemblies, each of them would implement the interface in a different way and thus have its own set of assembly dependencies. The key is to inject the appropriate behavior, which is typically done through configuration, but some IoC containers can also do that at runtime.