Added total size padding override. Documented unused parameter

[ZhekaS]

Fixes #101
Fixes #100

- Added an option --total-size-padding <padding> to override the default set by the specific architecture

• Added an optional ELF symbol tbf_total_size_padding lookup that sets the override of the architecture specific padding
• Added a note about --minimum-ram-size that it has no effect

[bradjc]

* Added a note about `--minimum-ram-size` that it has no effect

Yes.

* Added an option `--total-size-padding <padding>` to override the default set by the specific architecture

I have two reservations about this option.

1. It applies to all architectures. This would easily make invalid arm apps, or very large riscv apps.

2. I think I generally understand the issue this is trying to address, but this option could hide an annoying failure case for users: they have two TABs for the same app, with the same architecture list, and one works and one doesn't. We've skirted around this issue by maintaining the assumption that architecture == MPU requirements.

   If we want to change that assumption, I would prefer that it be explicit so that users and tockloader can reason about the correct tbf to install, and when a tbf will not work on their board.

   We could have tockloader handle this. Or, we could include all riscv apps twice at different paddings. Or we could just change elf2tab to use the larger padding. Or we could have a more targeted flag to build with a different size. But I would like to have the upstream elf2tab continue to work across tock boards.

[ZhekaS]

2. I think I generally understand the issue this is trying to address, but this option could hide an annoying failure case for users: they have two TABs for the same app, with the same architecture list, and one works and one doesn't. We've skirted around this issue by maintaining the assumption that architecture == MPU requirements.
   If we want to change that assumption, I would prefer that it be explicit so that users and tockloader can reason about the correct tbf to install, and when a tbf will not work on their board.
   We could have tockloader handle this. Or, we could include all riscv apps twice at different paddings. Or we could just change elf2tab to use the larger padding. Or we could have a more targeted flag to build with a different size. But I would like to have the upstream elf2tab continue to work across tock boards.

OK, I think I see the issue that I totally missed when working on this PR, that the TAB might actually contain many TBFs with different size requirements. I guess a more targeted flag is indeed required.

EDIT:
@bradjc Do you think something like --total-size-padding=<arch>,<padding> would work?

EDIT2:
Alternatively, limit this functionality to the case when only a single ELF is supplied (however this is more of a workaround for a very specific case, as we might want to pack multiple ELFs for the same arch).

[ZhekaS]

@bradjc I think the most "granular" control could be achieved by optionally passing the required padding size via a metadata in the ELF file itself, similarly to tbf_protected_region_size. Should I update the PR with the proposal?
Updated the PR with the proposal