How do I add a value to anywhere Input.GetAxis("Horizontal") is called?

See if the input manager is sufficient for what you require. I doubt that, but you could have a look.

From your post, we can't tell what OS you're using. The input system in Unity is intended to deal with platform dependent input API's, providing a platform independent means of gaining input. It is largely configured internally toward that purpose, where the input manager dialog allows "gross level" changes, usually selecting which among several attached devices provides a particular input recognized by the "keys" given, like "Horizontal" to the GetAxis call.

However, your description hints at a potentially better solution. I assume by UDP you mean you're getting packets of data via a TCP/IP configured connection. There is, actually, a common theme among a variety of applications doing this for multiplayer gaming. While your application is not that type, the underlying technical points are nearly identical.

What I suggest is that you view this from the same object oriented programming perspective which gave rise to the Input class (and system) in Unity, but since I sense Unity's input system isn't geared to your particular, unique, requirements you should implement your own. This is the essence of object oriented design and programming.

The whole reason Input works as it does is because all code uses calls to methods or properties of the Input class to gain input information during the time slice of Update or FixedUpdate functions, even though the input comes from different times (key ups and downs, for example, don't happen in sync with the Update function).

If you create a class which represents your input interests, you can wrap all input interpretations in the way you need, which can still consume services from the Unity Input class, or from your own unpacking of packet information. It would end up being the same as if you could rewrite the Unity input system to suit your needs, without having access to their code for doing that. This, too, is part of the object oriented paradigm, the notion of wrapping concepts into a class. Unity's Input class already wraps very different input sources into a single interface. An interface class like I'm proposing extends that very same design.

First, create a class that will represent your version on Unity's Input class. This is the basic "wrapper" style class, where, at first, during the initial development phase, you're merely forwarding calls to your class to Unity's Input. Many of the functions you call are static methods of Input, so you create similar static methods which merely forward calls to Unity.

Then, your application is merely edited to change Input. calls to your class. Let's say you call your class ExInput. You could fashion ExInput so that throughout your code, you merely add Ex in front of all Input calls. You've now "absorbed" Input into your class, but you can now interrupt anything you required.

Now, consider the ExInput method GetAxis, when the key is "Horizontal". Instead of forwarding that to Unity's Input, you unpack data coming from UDP to return what you require.

This implies that you'll probably have a thread running which accepts the appropriate UDP data, unpacks it and stores the results in ExInput static member variables representing the incoming data, which is loosely the description of what Unity's Input system is doing from a wide variety of input sources. With this model, you have complete control without having to write multiple input checks (using Input for some things, ExInput for others).

Trust the compiler to realize some of these "wrapper" functions do nothing, and elide the multiple calls implied. However, you may prefer the simplicity of only replacing GetAxis, and that's a reasonable choice (which is to say you'd use ExInput only for GetAxis, and Input for all other I/O). My underlying theme is that I assume re-configuring Unity's Input system isn't going to get what you need, and you really must interpret the packet data to provide that as information to your input requirements. You likely need a thread to serve the incoming UDP packet reception and unpacking, forwarding that to a class with static methods used to retrieve the interpreted results.