Fix relocation algorithm description

[jwerner-chromium]

This patch fixes a mistake that crept in during review of PR #6 (patch 062d542). The alignment_offset calculated from tl_base_addr was not superfluous in that calculation -- in fact, this is the only way in which tl_base_addr entered the calculation at all. If we don't have this, relocation for base addresses that do not already happen to match the highest alignment requirement won't work.

Also fix another small mistake in the same algorithm regarding calculating the new tl.max_size.

[sjg20]

This is really confusing.

Can we use alignx() to align to x bytes?

Then I think some of these expressions might become more intuitive

[jwerner-chromium]

Can we use alignx() to align to x bytes?

Well, we do use align8() where applicable, but this case is not so simple. It's not just aligning a value, it's masking off the offset from the previous alignment boundary, and then adding that to the down-aligned new address. Since those are a bunch of unique operations that only appear here in this document I think it's probably clearer to write them out directly rather than define new shorthands that would only be used in one place (especially since the alignment operation here is aligning down, whereas the align8() we use elsewhere means aligning up).

[sjg20]

As I've never quite been a fan of the idea of maintaining an alignment offset, I would prefer not to comment on this one. I'm approving and will let Dan decide

[danh-arm]

I'm good with this and Julius's rationale for not introducing new alignment macros