[WIP] add externalFile support to Contents section

[drh-stanford]

This PR fixes #485. It adds External File information into the Contents section of the catalog show page. The _default_contents.html.erb has ZERO tests, and all the data parsing, etc. is done in the view that is far from DRY. I did a major overhaul of the code formatting for the view to make it more readable hopefully. The only real part I added was the support for the externalFile elements. To test it, you need to create a contentMetadata datastream that has data as described in #485. If the manual testing is not acceptable, then I'd prefer to refactor how the view works (recommendations?). I also made some minor adjustments to the CSS styling.

Here's what the new display looks like:

[mejackreed]

Sigh... so your work looks great here. The sigh is for the view stuff already in there. A few thoughts on how to approach.

• We really shouldn't be assigning variables in the view like this. This is an actual use case for moving logic to a helper.
• There is a big opportunity to break this out into multiple partials. I could see something like _default_contents_resource.html.erb and _default_contents_file.html.erb. Each of those individual partials could be passed the locals it needs to render properly.
• ContentMetadata resources could be broken out into their own classes. This would be useful for testing purposes and maintainability. sul-embed does something similar here with its Resources and ResourceFile classes generating objects based off of purlxml: https://github.com/sul-dlss/sul-embed/blob/master/app/models/embed/purl.rb#L138-L204

This is a tough one, not sure what the best way moving forward is on all of this or how much we can actually get done.

[drh-stanford]

Because there's so much refactoring to be done, perhaps we should open a new technical debt issue for it? This PR just does some cleanup, no refactoring.

[mejackreed]

I'm 👌 with that.

[drh-stanford]

ok i created #536

[drh-stanford]

@mejackreed is there anything else I should address in this PR?

[atz]

can_manage, can_view, etc. really aren't defined anywhere else in the application? I swear I've seen the same logic before. Helper would be reasonable.

Side note: I prefer the long-line version of those assignments instead of the ugly paragraphs.

[dazza-codes]

This PR will have conflicts with the APO PR because of the user permission calls like can_manage or can_view. So if this is go ahead, it's a blocker for the APO PR and that will have to be rebased on this.

Blocks #532

[drh-stanford]

ok, i marked this WIP until #532 clears

[dazza-codes]

The #532 changes that conflict with this can be seen clearly in ea1b53b

[drh-stanford]

I will resubmit this later...