After much poking around, I finally figured out how to make this work!
The problem was that the ChibiOS initialization code had disabled
interrupts before the __early_init function was run, making the
bootloader not work despite my best intentions.  This was fixed by
enabling interrupts just before jumping to the bootloader.  This in turn
required changing to GNU-flavored C11 to include an inline assembly
instruction.

Due to an error when adding the different current definition types, the
flags configuration field never said (none).  Now it does once again,
and there's no trailing space when printing flags.

This commit adds support for configuring the current requested from the
power supply in the form of a resistance.  This is useful for powering
resistive loads when a voltage range is configured.

Previously, we didn't make use of the voltage range when checking a
Type-C Current advertisement.  That was bad, since if e.g. we want 6 V,
with the range 5-7 V, we could get the power we want from Type-C
Current.

This commit makes the firmware test if the configured voltage range
contains 5 V, and if it does, allows use of Type-C Current.

Now the DPM tests if the configuration holds a current or a power, and
if it's a power, it calculates current at the necessary voltage(s) based
on that power.  This is used when making requests, when advertising our
Sink_Capabilities, and when checking Type-C Current advertisements.

Previously, the PDO attribute getter macros took a capabilities message
and the PDO index.  This worked in a lot of cases, but not in some I
need now, and there was little advantage to them working they way they
did anyway.  Now they take just the PDO itself, which is more intuitive
and more useful.

This commit adds the `set_p` command for setting power, and the `p`
configuration field for reading it back.  There is no support for making
requests based on power yet (the field is still interpreted as a current
unconditionally).

I had intended the voltage range to be right after the voltage, but
accidentally put it after the current.  Fixed.

Now the Sink_Capabilities message contains a PDO from inside the range
if applicable, and a PPS APDO if we're using PD 3.0.

Now when we make a request from a voltage range, if the HV_Preferred
flag is enabled, we iterate over the PDOs backwards, so we see
higher-voltage fixed supply PDOs before lower-voltage ones.  This causes
the flag to do what it's supposed to.

The code to find a PDO from the range has been factored out into its own
function which will be used when building a Sink_Capabilities message.

Requests for fixed voltages are now made from the voltage range.  This
isn't a terrible behavior, but I might want to be able to make requests
from programmable supplies from the range as well.  'Twould be more
complicated though, and provide comparitively little benefit.  I'll
think about it, and maybe put out a request for comments.

Just as described in console_config.md.  Soon the DPM will even use the
range when making requests.

PPS APDOs are second priority, behind fixed supply PDOs.

This state requires that the DPM be informed of the receipt of a
Not_Supported message.  Some DPMs may not need to do this, so the new
dpm.not_supported_received function is optional.

This commit breaks old configuration by interpreting stored voltages as
millivolts, rather than 50 mV.  This will allow the finer voltage
increments used by programmable power supplies to be specified.

Now the commands are in the same order in shell.c, the printed list, and
console_config.md.

Now the CURRENT_DEFN field of the flags halfword in the pdbs_config
object is actually used, both when printing configuration objects and
when setting a current.  It never takes any value other than 0 (_I) yet,
but this easily extends to power and resistance.

This commit adds the toggle_hv_preferred command, and makes printed
configuration objects show the state of the HV_Preferred flag.  The
flag still isn't used by anything else yet though.

Due to a typo, it would clear all bits except the HV_Preferred bit.
This commit fixes the bug, and refactors the clearing code to make typos
like this harder to make.

Firmware 1.2.0 will have more configuration flags than previous
versions.  This commit adds macros for those flags.  There's also a
field added to the flags halfword that says whether a current, power, or
resistance is configured, so this commit makes the clear_flags command
not modify that field.

Now instead of checking the Var/Bat flag, it checks if either end of the
range is non-zero.

The new tempate variable sets the data role, power role, and
specification revision in one fell swoop.  It's used by the PE and DPM
alike for creating messages, and in the future it may have a part in
determining if we're doing PD 2.0 or 3.0.

All the internal functions and definitions have been moved out of
lib/include/.  Includes are made with the semantically correct brackets
("" or <>) throughout the firmware and library.  That is to say, the
library is essentially done at this point, with only documentation
changes left to be made.

This commit splits the old messages.h file into two, one private
(messages.h) and one public (pdb_msg.h).  This new arrangement keeps the
old model of one message pool for all the PD Buddy firmware library, but
moves the macro for the number of objects it contains into a new file,
pdb_conf.h, placed at the project root.  The pool itself is kept in the
new pdb_msg.h file, since the DPM may need to access it.

The new configuration file also contains the stack sizes for the PD
Buddy threads (some will be moved back to secrecy in the future once the
needed sizes are known, but the PE's stack size should be kept in
pdb_conf.h since user code needs that stack).

To do this, a couple of the events had to have their definitions moved
to lib/include/pdb_pe.h.  This isn't a problem in and of itself, but if
more internal-use events are added to policy_engine.h there could be
trouble.  To mitigate this, I added a comment as a reminder to make sure
any new events don't overlap the public ones defined elsewhere.

Their names were a bit too greedy for the global namespace, so I
changed them to start with fusb_tcc_.

Again, shining example and whatnot.

Not the static globals yet, just the public ones.  I suppose this change
isn't technically necessary since the PD Buddy Sink is a single-port
device, but I want its firmware to be a shining example of how to use
the library.

Now all the FUSB302B functions exclusively use the struct
pdb_fusb_config to know how to communicate with the chip.

It isn't used there, so it doesn't need to be included.

It's not general-purpose PD Buddy code, but rather PD Buddy Sink code.
Therefore it gets the pdbs namespace.

The code compiles again, and it seems to work as it did before.  There's
still a lot to do (we still have a mess of globals), but the PE
correctly calls the new DPM functions via the list of callbacks in the
configuration object.

For now, the new <pdb.h> file only has a function to start the library,
based on the old start_pd function from main.c.  It'll eventually be all
a user needs to include, but there's a lot more refactoring to do.

/!\ BROKEN BUILD /!\

This commit moves the library code to the library directory.  This
causes the firmware to not compile.  A few changes were made to reduce
the nubmer of errors, but some errors just aren't going to go away until
I go ahead with the planned changes.

When we receive a GotoMin message, we immediately go to lower power
before entering the PE_SRC_Transition_Sink state.  Therefore, the call
to pdb_dpm_output_set was redundant in this case.  Now the call isn't
made in this case, removing the redundancy.  This also leads somewhat
into the design of the new library.

The "storage" source code files contained lots of stuff with "config" in
the name, but nothing named "storage".  This was unlike every other part
of the firmware, so I renamed the files to "config".

Now the call to fusb_get_typec_current is made in the policy engine,
then passed to pdb_dpm_evaluate_typec_current.  This is more consistent
with pdb_dpm_evaluate_capability, improving the PD Buddy DPM API.
That's right, I'm thinking about API design now for when I split the
code into a library and application.

Now that we cache the configuration location in the configuration code
itself, we don't need to cache it elsewhere.  This makes the DPM code
for evaluating Type-C Current much cleaner.

Until now, the valid configuration object's location was not stored, so
it had to be looked up every time pdb_config_flash_read was called.  Now
the valid object's location is stored in config_cur, which is updated
every time the configuration's location changes.  This means that
pdb_config_flash_read only has to do the full routine the first time
it's called, or after pdb_config_flash_erase is run.  Now other parts of
the configuration won't have to cache the location themselves anymore.