add `Format` impls for `std`

[rursprung]

while almost all consumers will use core and maybe alloc few are using std, thus this has not been a problem yet.
to get started i've created #978

if std types support is an explicit no-goal (i.e.: it should never be added) then the PR can of course be rejected and instead the README should maybe be updated to state this.

[jonathanpallant]

std support is a nice to have, but it's blocked on:

• the "symbols are JSON" trick makes the Windows and macOS linkers very sad
• there are no example transports for getting log strings out of a std application

So, until we've fixed that, impl defmt::Format for std::foo is moot

[korken89]

Here you can use the method we used in the fasthosting project, that was prototyped along side defmts early development, but allowed also printing of any DWARF symbol if it did not have a Format impl. This was however back then blocked on no const fn type_name.

The main logging macro expands as follows: https://github.com/korken89/fasthosting/blob/master/log0_target/src/lib.rs#L98-L143
Where the interesting parts are:

• The linker symbol is not a JSON, see: https://github.com/korken89/fasthosting/blob/master/log0_target/src/lib.rs#L113-L119 - thinking about it defmt could probably adopt this today and move away from the JSON-in-debug-symbols issue.
• For DWARF print-ability:
  • With the stabilization of const fn type_id we should not be far away from const fn type_name (Tracking issue for const fn type_name rust-lang/rust#63084).
  • Getting hold of the targeted types is made before calling write (to host) method: https://github.com/korken89/fasthosting/blob/master/log0_target/src/lib.rs#L8-L11 (this is if you want to print anything via it's DWARF representation).
  • This can become a const fn, and at that point you can place the type string in any linker section you want (e.g. a info section 😉 ) as my motivating example in the type_name tracking issue shows.

[jonathanpallant]

So it looks like you place the format string in the value not in the name. This has the side effect of making the size larger than 1 and burning through addresses faster. This then needs more bytes for the message ID (which is the address). I've thought about this but I'm not sure I'm fully convinced.

[korken89]

Yeah, we did not do any kind of optimization around sizes at this time. We did discuss having one step of indirection so you can get a list of indexes for each formatting string, but we never did any work on it.

If I remember correctly then the plan was to have basically 2 INFO sections as follows, so the first one is a jump-list to the next:

SECTIONS {
  .jumplist (INFO) :
  {
    *(.jumplist.*);
  }
  .formatting_strings (INFO) :
  {
    *(.formatting_strings.*);
  }
}

Not sure if I got this right from my memory, but I hope you get the idea. You would then limit the index sent over RTT.
I remember that this should make it possible to get back down to 1 byte indexes, as each entry in the jump list is N byte aligned you can sent the jump list address / N (with N being ptr size).

But the main focus was to get DWARF to format for us :)