Refactor files and document with dependencies

[DaveParr]

• Used sinew to write namespace makeimport, thanks @maelle
• Used mostly one file per project
• Wrote function to set environmental variables: np_credentials()
• Wrote function to create 'id' of icon string
• Extended documentation at various small points

[DaveParr]

I think the 'form' we should take is: Each developer, on their fork of the repo, can kind of do whatever. I suggest

• branch from myUser:master to myUser:myFeature
• complete work on myUser:myFeature
• merge to myUser:master

The developer then has their 'working' code in their master branch. To check it's compatibility they had the organisation repo caRdiffR/nounprojectR:master set as a remote called upstream like this example. they then 'sync with an upstream remote'

• fetch upstream from caRdiffR:master
• they, as developers, deal with any conflicts that arise
• issue a pull request from myUser:master to caRdiffR:master
• we merge pull request

Doing it this way means they have already dealt with keeping themselves up to date with other changes, making the PR easier to merge for us. The links are the GitHub issued docs which I think encourage this usage.

An alternative is possible:

• issue pull request from myUser:master to caRdiffR:master
• we, as organisers, deal with updates to the code base in the GitHub conflict resolution tool
• we merge the pull request

(I know right now it's basically just us in both roles, but I still think this is good practice for us to do the full job when wearing the relevant hat :))