Fix endpoints when the service only listens on one IP address

If we let the service bind to all IPs, then the service is obviously
usable from the public and admin networks. Otherwise, the endpoint URLs
should use the unique IP that will be listened on.
Don't hardcode the username in cron files (bnc#826117).

In our tests it surfaced in /etc/cron.d/glance-scrubber.
In SUSE packages the user is openstack-glance.
Move registration of glance service user to common recipe

There's no need to have that code done twice for both api and registry,
which was also causing a CHEF-3694 bug (since the resources had the same
name).

WARN: Cloning resource attributes for keystone_register[register glance user] from prior resource (CHEF-3694)
WARN: Previous keystone_register[register glance user]: /var/chef/cache/cookbooks/glance/recipes/api.rb:108:in `from_file'
WARN: Current  keystone_register[register glance user]: /var/chef/cache/cookbooks/glance/recipes/registry.rb:85:in `from_file'
WARN: Cloning resource attributes for keystone_register[give glance user access] from prior resource (CHEF-3694)
WARN: Previous keystone_register[give glance user access]: /var/chef/cache/cookbooks/glance/recipes/api.rb:118:in `from_file'
WARN: Current  keystone_register[give glance user access]: /var/chef/cache/cookbooks/glance/recipes/registry.rb:95:in `from_file
Merge pull request #92 from vuntz/fix-endpoint-when-bound

Fix endpoints when the service only listens on one IP address
Merge pull request #93 from mvidner/cron-username

Don't hardcode the username in cron files (bnc#826117).
Merge pull request #94 from vuntz/fix-CHEF-3694

Move registration of glance service user to common recipe