Rename .ccb, .ccbi, and .ccbproj extensions to .sb, .sbi, .sbproj

[andykorth]

These commits complete the cocos2d pull request: cocos2d/cocos2d-objc#1244

All the ccb file extensions have been changed to .sb. Unit tests have been updated, and the template project is also updated. So don't forget to recreate the template project. Use Donald's new rakefile, it's amazing!

The commits have been broken up to more easily separate actual changes from bulk renames done by XCode. In the first commit, the file extension references have been extracted into constants.

Unlike my cocos2d changes, I didn't rename any source code files. There are a lot more of them here.

I've updated the file associations for spritebuilder. In the case of .ccbproj and .sbproj, I've left both file associations in the app, to ease the migration process. New projects will be made using a .sbproj file.

A migration script is pending, @NickyWeber volunteered to take a look, since he's working on a bunch of migration related work. Thanks!

Be sure to use with the corresponding cocos2d changes in cocos2d/cocos2d-objc#1244

[NickyWeber]

@andykorth Can you have a look at the failed build on the test server? Something about CCSBReader_Private.h missing. Cocos2d submodule up to date?

[andykorth]

Yeah, it seems like the test server didn't pull the changes in cocos2d/cocos2d-objc#1244. On one hand, I didn't update the submodule, so obviously it couldn't. On the other hand, will it find unmerged changes even if it has the right SHA? Presumably not, but...

I'll give it a try and find out.

[andykorth]

Yeah, as expected, it can't check out the unmerged pull request for cocos2d. Anyone have any insights on how we could get this working with the continuous integration system?

Merge the cocos2d pull request, then quick re-run the test?

[NickyWeber]

It should automatically rerun the tests as soon as you merge the cocos2d stuff, then bump the version and commit to this PR.

[rkachowski]

Can you rebase this onto the most recent develop? This PR contains a lot of my commits that are already merged and the diff is pretty hard to read

[andykorth]

So I pulled the most recent develop and did the rebase. It looks like github is still showing your commits here.

It might be convenient to look through them commit by commit anyway, since some were just big auto-renames.

[andykorth]

@rkachowski did you rebase these commits? So the ones I have weren't the same ones that were actually commit into develop? I could cherry pick my range of commits, perhaps?

I also got a lot of conflicts while doing the rebase, so perhaps that's a bad sign.

[rkachowski]

if you use git rebase -i develop (assuming you have the latest develop on your local repo) you get a list of all the commits in your branch. You will be able to remove all the irrelevant commits by completely deleting the line that represents them.

If you solved all the conflicts during the rebase, you've likely changed each individual commit to contain the necessary resolution. You can get back to your original pre-rebase branch by looking in git reflog, finding the correct HEAD{@blah} line and doing a git reset --hard [ref goes here].

I regularly rebase feature branches that are on my personal fork to keep them compatible with the most recent builds. I do this instead of merging develop into the feature branch as it keeps the included commits and diff strictly relevant to the feature at hand, and I assume unless someone has commented on a pull request that it's unseen and safe to modify.

[NickyWeber]

@andykorth I guess it's best if we don't proceed with this PR. To move on I had to make many of the changes you did myself in a certain order. I'll go and "cherrypick" some changes of yours for completeness. Thanks.