You have three options for a new arm:
(1) Write a plugin for your arm: The plugin provides a direct C++ interface to any kinematics solver. If you implement the plugin for your arm, you can configure the generic kinematics node in the arm_kinematics_constraint_aware package to use this plugin. This saves you the trouble of configuring/writing your own constraint/collision aware kinematics package. This node advertises all the right services for use with move_arm.
(2) Provide a GetConstraintAwarePositionIK service for move_arm to use by writing your own node that duplicates the services provided by the arm_kinematics_constraint_aware node (and also by the pr2_arm_kinematics node).
(3) Use the arm kinematics node in the arm_kinematics_constraint_aware package configured with the KDL solvers for your arm. A tutorial for this is here: http://www.ros.org/wiki/arm_kinematics_constraint_aware/Tutorials
Option (3) is the simplest but maybe not the most efficient solution. (1) is the way to go if you have a custom implementation of kinematics for your robot. It will also be the most efficient option. Option (2) will probably require the most work on your part.
This is an answer to Martin's follow up question/comment:
The way I envision this playing out in the future for anyone writing a custom kinematics solver for their arm:
(a) Write the custom kinematics implementation as a library
(b) Wrap it in a plugin - this allows you to (at runtime) configure (in YAML) components like the motion planners to use your kinematics implementation
(c) The generic kinematics node in arm_kinematics_constraint_aware can also use your plugin to expose the kinematics as ROS services. This is useful for things like move_arm which expect to communicate with everything over ROS.
Plugins allow easy runtime configuration using YAML - that is explicitly what they are meant for. They also give you a straight C++ interface which is more efficient (if you are going to call the kinematics thousands of times) than calling out over ROS services. This is important when a motion planner working in task space calls the inverse kinematics repeatedly. This is the way the pr2_kinematics is now configured for use with OMPL in ompl_ros_interface.
The ROS node exposes ROS functionality that is convenient for you to use and allows distribution of this functionality over multiple computers. In the future, the ROS node offering kinematics services for the PR2 will change over to using the plugin infrastructure. This is a change that will happen under the hood without affecting any users.
