Why complicate you build for this, when it's a deployment problem. Most containers deploy WARs in an "exploded" form, which means that somewhere on you file system is the spring.xml file.
If you'd like to update that, you can simply locate the actual location and then copy your new spring.xml over the old one. Yet, at the same time, your WAR remains the de riguer "source of truth".
WARs tend to be very simple to use and deploy, so there's a benefit to bundling your configuration as best you can in the WAR.
So, you can update the spring.xml by going behind the back of the container, and editing it (or copying over) it directly.
Finally, having the spring.xml outside of your WAR means that's it's available to ALL of your WARs, and if you decide later to add another WAR to your system, you will likely have difficulty segregating the two files as they are no long anchored to a specific WAR.