Rationalize info pages repository

[sfisher]

The files in the info-pages repository add complexity and confusion It seems they exist in triplicate on a server deploy and maybe two or three times on a developer machine (depending how it was configured).

• ezid/templaces/info is the one that is really used for the files I made edits to, though maybe there is an exception for some files.
• ezid/static_src/info got copied into the repo a few years ago, but I don't think they needed to be (at least not most of them). The static_src are for completely static files which get "compiled" (minified?) or just copied into . . .
• ezid/static/info (where the files from static_src get copied with the collectstatic task) The purpose of the static directory is that files that don't need dynamic rendering with Django can be served by a dumber and faster web server (like Apache) instead of going through the Django rendering pipeline.

At minimum, I believe we should remove extra copies of files that are not really used or useful to avoid confusion and changing the wrong files that don't give the output expected.

• Anything served by Django dynamically (and has entries in urls.py) doesn't belong in the static directories at all and should only be in the templates/info.
• Anything that is truly static and isn't served by Django should be removed from templates/info and I put in static_src and then have collectstatic run (which puts it in static).

In addition, I think we should consider deprecating and archiving the info-pages repo and just moving those files into the main repository and removing the extra deploy step of getting those files from a separate repository. My reasoning for this is:

• I think that separate repository was created to make it easy for a product manager to change text . . . but
  • Github allows editing text on their web site and creating new commits directly to the main branch's code (bad) or creating a commit to a new branch and then do a pull request (good) which allows someone else to double-check for something like an accidentally missing tag or anything before merging (which prevents some possible weird layout issues or other minor accidents or other things).
  • I believe we need to pull the updates to the info-pages repo code and restart ezid for info-pages commits to go into effect right now, anyway. I guess incorporating it into the main code might mean we may want to wait for release days for text changes in some cases. IDK if that is a big deal. It could cause more tagging and releasing just for text changes if they really happen frequently outside of a normal release cycle, but I don't think they usually do (or need to) happen outside a normal release cycle very much. Maybe sometimes we want to place a status message someplace, but getting a message from the database or a status blog might even be easier than re-deploying the info pages.
• Info pages adds an extra repo and step to the deploy and extra setup on a developers machine.
• When looking at the history of that repo and the commits, the changes are made very infrequently, so I don't think there is usually a burning need to make lots of updates and to separate them into a different repo and from a normal deploy process.

I'd be curious what other people think and if we think the benefits of doing it that way outweigh the drawbacks.