Closes #173.

This PR implements automatic sizing of the attribute table when using the gatt_server macro.
The number of attributes for each service is calculated in the gatt_service macro, and this is then summed up by the gatt_server macro to determine the size of the table.
The option to override this and manually set the attribute table size still exists.
I have also renamed the attribute macro argument to attribute_table_size as this more accurately reflects the value being set.

Topic for discussion

I have implemented a static assertion to throw a compile-time error if the table size is overridden with a value too small to hold the calculated number of attributes. The advantage of this is of course that the user will be notified before flashing their device, meaning that they do not need to be monitoring the device's trace to see the issue.
However, I cannot use formatted strings in a "constant assertion", so the compile-time error looks like this:

error[E0080]: evaluation of constant value failed
  --> src/ble_bas_peripheral.rs:22:1
   |
22 | #[gatt_server(attribute_table_size = 9)]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'Specified attribute table size is insufficient. Please increase attribute_table_size or remove the argument entirely to allow automatic sizing of the attribute table.', src/ble_bas_peripheral.rs:22:1
   |
   = note: this error originates in the macro `$crate::panic::panic_2021` which comes from the expansion of the macro `core::assert` (in Nightly builds, run with -Z macro-backtrace for more info)

The alternative would be to use a normal assert! which would be evaluated at run-time. This would allow a formatted message of something like:

====================== PANIC ======================
panicked at /home/pkubiak/repos/trouble/examples/apps/src/ble_bas_peripheral.rs:22:1:
Specified attribute table size of 9 is insufficient. A table size of at least 10 is required for the current GATT server configuration.

but of course this would only be visible in the device's trace.

I personally lean toward the static assertion, but I'd be keen to hear other opinions on this!