Make bikes_allowed a recommended field in GTFS

## Context
As part of our efforts to merge the GTFS Best Practices into the spec, we are:
1. migrating the current Best Practices into the spec based on community consensus ([plan for Schedule](https://github.com/google/transit/issues/396), [plan for Realtime](https://github.com/google/transit/issues/451)).

2. evaluating [all outstanding issues and PRs](https://github.com/google/transit/issues/421) that existed on the Best Practice repos, and proposing new Best Practices to be added directly into the spec, if still relevant.

## Scope for this issue
This issue picks-up on https://github.com/MobilityData/GTFS_Schedule_Best-Practices/pull/56 by @bdferris-v2 aiming at making `bikes_allowed`a recommended field in GTFS.
We would update the presence requirement from _Optional_ to _Recommended_, and datasets that don't have this fields would get the [missing_bike_allowance](https://gtfs-validator.mobilitydata.org/rules.html#missing_bike_allowance-rule) canonical validator notice for all trips (currently just ferry trips).

## Considerations
1. What are other GTFS fields currently recommended?

feed_start_date, feed_end_date, feed_version.

3. Why aren't we just making all optional files/fields recommended?

Certain Optional files/fields are dependent on the service (e. g. timeframes.txt is for modeling fares based on time of day), whereas other files can and should always be added regardless of the type of service being modeled (e. g. feed_info.txt). We think there is value in calling out the latter explicitly using the term _Recommend_ to promote higher-quality GTFS.

**Would you support this change?**
Tagging folks who engaged in adding the Recommended presence into GTFS @e-lo @antrim @bdferris-v2 @NomeQ @gcamp @evansiroky @markstos @westontrillium @derhuerst @doconnoronca @dekarl